Product Mention Detection and Resolution Prompt Template

This prompt is designed for operational teams—e-commerce catalog managers, market intelligence analysts, and support operations engineers—who need to extract product references from unstructured text and resolve them to canonical SKUs or catalog entries. The core job-to-be-done is consistent entity resolution: turning a messy mention like 'the new iPhone' or 'Coke Zero' into a structured, queryable reference such as SKU:IPH15P-256-BLK or Brand:Coca-Cola, Product:Coke Zero Sugar. Use this when your workflow requires downstream analytics, ticket routing, or competitive monitoring that depends on accurate product identification, not just keyword matching.

This prompt assumes you have a catalog, SKU list, or product master data available to inject as [CONTEXT]. It is designed to handle model numbers ('XPS 15 9530'), generational variants ('iPhone 14' vs 'iPhone 14 Pro'), informal nicknames ('Coke' for 'Coca-Cola Classic'), and ambiguous mentions by using that context to disambiguate. Do not use this prompt when the goal is product search, recommendation, or marketing copy generation. It is not a retrieval system on its own; it resolves mentions against a provided catalog. It is also not a general-purpose NER model—it focuses exclusively on products and SKUs, not people, locations, or organizations. For high-risk domains like regulated product claims or safety recalls, you must route low-confidence resolutions to a human review queue and never treat the model's output as authoritative without verification.

Before wiring this into production, define your [OUTPUT_SCHEMA] to match your downstream ingestion contract—typically a JSON array of objects with fields for mention_text, resolved_sku, canonical_name, and confidence. Plan for failure modes: the model may resolve a mention to the wrong SKU if your catalog context is incomplete, or it may miss a mention entirely if the product is described in highly idiomatic language. Start by running this prompt against a golden dataset of 50–100 annotated examples to calibrate your confidence thresholds and decide when to escalate to human review. The next section provides the copy-ready template.

This template is designed to be pasted directly into your system instructions for a model call. It instructs the model to identify product references—including informal nicknames, model numbers, and generational variants—and map them to your canonical SKU or catalog ID. The prompt uses strict square-bracket placeholders that you must replace with your specific data before sending the request to the model. Do not leave any placeholder unresolved in production; missing context will cause the model to hallucinate catalog entries or miss mentions entirely.

textCopy
You are a product mention detection and resolution system. Your task is to analyze the provided text and identify all references to products. For each mention, you must resolve it to a single canonical entry from the provided product catalog. If a mention cannot be confidently resolved, flag it for human review instead of guessing.

## INPUT
[INPUT_TEXT]

## PRODUCT CATALOG
[PRODUCT_CATALOG_JSON]

## RESOLUTION RULES
- Match against product names, model numbers, SKUs, and known informal nicknames listed in the catalog.
- For generational variants (e.g., 'iPhone 14' vs. 'iPhone'), resolve to the most specific matching entry. If the text is ambiguous, select the latest generation unless context indicates otherwise.
- If a mention matches multiple catalog entries with equal confidence, flag it as ambiguous.
- If a mention has no plausible match in the catalog, flag it as 'unresolved'.
- Do not infer a product mention from accessory, part, or service descriptions unless the core product is explicitly referenced.

## OUTPUT SCHEMA
Return a valid JSON object with a single key "product_mentions" containing an array of objects. Each object must have the following fields:
- "mention_text": The exact string from the input text.
- "canonical_sku": The resolved SKU from the catalog, or null if unresolved.
- "canonical_name": The resolved product name from the catalog, or null if unresolved.
- "confidence": One of "high", "medium", or "low".
- "status": One of "resolved", "ambiguous", or "unresolved".
- "resolution_notes": A brief explanation of the resolution decision or the reason for flagging.

## CONSTRAINTS
- Do not return any text outside the JSON object.
- If no product mentions are found, return {"product_mentions": []}.
- Do not fabricate SKUs or catalog entries.

Before deploying this template, replace [INPUT_TEXT] with the raw text you want to analyze and [PRODUCT_CATALOG_JSON] with a structured JSON array of your canonical product records. Each catalog record should include at minimum sku, name, and aliases (an array of known nicknames or model numbers). For high-risk e-commerce workflows where incorrect resolution could lead to mis-shipments or pricing errors, always route low confidence and ambiguous status results to a human review queue. After adapting the prompt, run it against a golden dataset of 50+ annotated examples to measure precision and recall before production release.

This prompt is designed to be called from an application layer that manages the catalog context, not as a standalone chat interface. The application is responsible for assembling the [CATALOG_CONTEXT] variable—typically a pre-retrieved set of candidate SKUs, product names, model numbers, and aliases from your product master database. Do not send the entire catalog; instead, use a retrieval step (keyword search, vector search, or hybrid) to fetch the top-N candidates based on the input text before populating the prompt. This retrieval step is the single most important factor in resolution accuracy, as the model can only resolve mentions to products it can see in the context window.

The implementation should follow a structured pipeline: (1) Accept raw text input from the source system (chat transcript, review, support ticket, social post). (2) Run a lightweight pre-filter to detect whether the text contains any product-like language at all—this avoids wasting LLM calls on irrelevant content. (3) Retrieve candidate catalog entries using a search over product names, aliases, model numbers, and SKUs. (4) Assemble the prompt with the input text, retrieved candidates, and output schema. (5) Call the model with response_format set to json_schema (OpenAI) or equivalent structured output mode (Claude tool use with a strict schema, Gemini controlled generation). (6) Validate the output JSON against the expected schema before ingestion. (7) Route low-confidence results (below your defined threshold, typically confidence < 0.7) to a human review queue with the original text and retrieved candidates pre-loaded.

For retry logic, implement a single retry on schema validation failure with the validation error message appended to the prompt as additional [CONSTRAINTS]. If the second attempt also fails validation, log the failure and route to human review—do not loop indefinitely. For model choice, a capable mid-tier model (GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro) is sufficient for most product mention tasks; reserve larger models for cases with high ambiguity or when the catalog contains thousands of near-duplicate variants. If your product catalog changes frequently, implement a cache-busting mechanism on the retrieval step to ensure the prompt always receives fresh catalog data. Log every resolution with the input text, resolved SKU, confidence score, and model version for audit and eval dataset construction.

The output schema should include a resolved_sku field (null if no match), a confidence float between 0 and 1, a candidate_matches array with ranked alternatives, and a mention_spans array citing the exact text positions where products were detected. Downstream systems should treat confidence < 0.5 as 'no reliable match' and null resolved_sku as 'product mentioned but not in catalog.' Build an eval harness that tests against a golden set of 50–100 examples covering exact SKU mentions, nicknames, generational variants ('iPhone 14' vs 'iPhone 14 Pro Max'), misspellings, and texts with no product mentions. Run this eval on every prompt or model change before deployment. For high-stakes use cases like automated inventory linking or pricing, always require human approval on resolutions below your confidence threshold and maintain an audit trail linking each resolution to its source text and catalog state at time of processing.