Name Parsing into Structured Components Prompt Template

This prompt is a post-generation repair step for data engineers and CRM integrators who receive full name strings from upstream model outputs, form submissions, or third-party data sources. Use it when you have a single full_name string and need a reliable JSON object with given_name, family_name, title, suffix, and nickname fields. It is designed to handle multi-cultural name orders, compound surnames, and inconsistent formatting before the data enters a system of record. The ideal user is building a data pipeline where name components must be indexed, searched, or used for personalization and cannot tolerate unstructured blobs.

Do not use this prompt as a replacement for a proper name schema in your initial extraction prompt. If you control the upstream prompt that generates the name, add structured output instructions there first. This prompt is for repairing names that have already been generated as unstructured text. It is also not suitable for parsing names from free-text documents like emails or contracts where the name is embedded in prose—use a dedicated entity extraction prompt for that. For high-volume pipelines, pair this prompt with a validation harness that checks for missing required fields, unexpected titles, or single-name inputs before the record is written to your database.

Before implementing, confirm that your upstream model output or data source reliably provides a single full_name string. If you receive names split across multiple fields, you may not need this prompt at all. If you receive names in varying formats (e.g., 'Smith, John' vs. 'John Smith'), this prompt handles both, but you should log the input format for monitoring. For regulated environments where name accuracy has legal implications, always route low-confidence outputs to a human review queue. The next section provides the copy-ready prompt template you can adapt and deploy.

This prompt template converts inconsistent full name strings into structured JSON objects with fields for given name, family name, title, suffix, nickname, and middle name. It handles multi-cultural name orders (Western, East Asian, Hispanic, Arabic, Icelandic patronymics), compound surnames (e.g., 'van der Waals', 'de la Cruz'), generational suffixes (Jr., III), professional titles (Dr., Prof.), and parenthetical nicknames. The prompt is designed for data engineers and CRM integrators who receive name strings from model outputs, form submissions, or document extraction pipelines and need canonicalized records for deduplication and identity resolution.

textCopy
You are a name parsing specialist. Your task is to decompose a full name string into structured components.

INPUT:
[FULL_NAME_STRING]

CONTEXT (optional):
- Locale hint: [LOCALE_HINT]
- Known title list: [TITLE_LIST]
- Known suffix list: [SUFFIX_LIST]

OUTPUT_SCHEMA:
Return ONLY valid JSON with this structure:
{
  "title": string | null,
  "given_name": string | null,
  "middle_name": string | null,
  "family_name": string | null,
  "suffix": string | null,
  "nickname": string | null,
  "full_name": string,
  "parsing_confidence": "high" | "medium" | "low",
  "name_order_detected": "western" | "eastern" | "hispanic" | "patronymic" | "unknown",
  "ambiguity_notes": string | null
}

RULES:
1. Preserve compound surnames intact (e.g., 'van der Waals' stays in family_name).
2. Detect name order from structure, not assumptions. If 'Tanaka Hiroshi' arrives, family_name is 'Tanaka'.
3. Extract parenthetical nicknames: 'William (Bill) Smith' → given_name: 'William', nickname: 'Bill'.
4. Separate generational suffixes (Jr., Sr., III, IV) from family_name into suffix field.
5. Separate professional titles (Dr., Prof., Capt., Rev., Hon.) from given_name into title field.
6. If a name component cannot be determined, set it to null.
7. Set parsing_confidence to 'low' if the name has fewer than 2 components or ambiguous structure.
8. Include ambiguity_notes when the parse could reasonably produce different results.

CONSTRAINTS:
- Do not guess missing components. Use null.
- Do not normalize nicknames into given_name.
- Do not split compound surnames.
- Do not assume Western name order without evidence.

EXAMPLES:
Input: 'Dr. Maria del Carmen Rodriguez Jr.'
Output: {"title": "Dr.", "given_name": "Maria", "middle_name": "del Carmen", "family_name": "Rodriguez", "suffix": "Jr.", "nickname": null, "full_name": "Dr. Maria del Carmen Rodriguez Jr.", "parsing_confidence": "high", "name_order_detected": "hispanic", "ambiguity_notes": null}

Input: 'Tanaka Hiroshi'
Output: {"title": null, "given_name": "Hiroshi", "middle_name": null, "family_name": "Tanaka", "suffix": null, "nickname": null, "full_name": "Tanaka Hiroshi", "parsing_confidence": "high", "name_order_detected": "eastern", "ambiguity_notes": null}

Input: 'Bjorn Eriksson'
Output: {"title": null, "given_name": "Bjorn", "middle_name": null, "family_name": "Eriksson", "suffix": null, "nickname": null, "full_name": "Bjorn Eriksson", "parsing_confidence": "medium", "name_order_detected": "patronymic", "ambiguity_notes": "Patronymic surname detected; may not be a stable family name across generations."}

Input: 'Smith'
Output: {"title": null, "given_name": null, "middle_name": null, "family_name": "Smith", "suffix": null, "nickname": null, "full_name": "Smith", "parsing_confidence": "low", "name_order_detected": "unknown", "ambiguity_notes": "Single-component name; cannot distinguish given from family name."}

To adapt this template, replace [FULL_NAME_STRING] with the raw name input. Optionally provide [LOCALE_HINT] (e.g., 'JP', 'ES', 'IS') to bias name order detection, [TITLE_LIST] to constrain recognized titles, and [SUFFIX_LIST] to constrain recognized suffixes. The output schema is intentionally flat to simplify downstream ingestion. If your system requires separate fields for maternal/paternal surnames in Hispanic naming conventions, extend the schema with paternal_surname and maternal_surname fields and update the rules accordingly. For batch processing, wrap this prompt in a loop that validates each output against the schema before ingestion. Always run a post-processing validation step that checks for null family_name when given_name is present, as this indicates a parse failure that needs human review.

The name parsing prompt template is designed to be called as a single-step transformation within a broader data ingestion or CRM pipeline. It expects a raw full name string as input and returns a structured JSON object with components such as given_name, family_name, title, suffix, and nickname. The prompt should be treated as a stateless function: each call is independent, and no conversation history or session context is required. This makes it straightforward to deploy behind a REST endpoint, a queue worker, or a streaming processor. The primary integration surface is the model API call itself, wrapped in application code that handles pre-processing, post-processing, and error recovery.

Validation and retry logic is essential before the parsed output enters any downstream system. After receiving the model response, validate the JSON structure against a strict schema that requires at minimum a given_name and family_name field, both non-empty strings. If validation fails, retry the prompt once with the same input and an added instruction to return valid JSON only. If the second attempt also fails, log the raw input and model output for manual review and route the record to a dead-letter queue. For high-throughput pipelines, implement a circuit breaker that pauses processing if the failure rate exceeds 5% within a rolling window, preventing cascading failures. Model choice matters: use a model with strong JSON mode or structured output support (e.g., GPT-4o with response_format set to json_object, or Claude with tool-use mode forcing a typed output). Avoid models without native JSON guarantees for this task, as free-text name parsing is prone to format drift. Logging should capture the input string, the parsed output, the model version, the latency, and any validation errors for every call. This trace data is critical for debugging edge cases like mononyms, compound surnames, or multi-word given names that the model may handle inconsistently.

Human review is not required for every record but should be gated on specific risk signals. Flag records for review when: (1) the model returns a confidence score below 0.7, (2) the parsed family_name is empty or matches a known given-name-only pattern, (3) the input contains more than five space-separated tokens suggesting complex multi-part names, or (4) the output includes a nickname that does not appear as a substring or known variant of the given name. These flagged records can be routed to a review queue where a human operator confirms or corrects the parse before it enters the canonical data store. For regulated environments handling PII, ensure that the review interface masks unnecessary fields and logs all human actions for audit trails. Tool use and RAG are not typically needed for this prompt, as name parsing relies on the model's internal knowledge of naming conventions rather than external retrieval. However, if your pipeline handles names from a specific cultural context with known patterns (e.g., Icelandic patronymics, Spanish compound surnames), consider injecting a short reference table of rules as part of the [CONTEXT] placeholder rather than relying on the model's general knowledge alone.

What to avoid: Do not call this prompt in a tight synchronous loop on a user-facing request path without a timeout and fallback. Model latency can vary, and a blocking call will degrade user experience. Instead, use asynchronous processing: accept the raw name, return an immediate acknowledgment, and update the record when parsing completes. Do not skip the deduplication check after parsing: two different raw name strings (e.g., 'Dr. Jane Smith' and 'Smith, Jane') should produce identical canonical components, and your pipeline should detect and merge these duplicates. Finally, do not treat the model's output as ground truth without validation—name parsing is surprisingly ambiguous, and even high-confidence outputs can be wrong for edge cases like reversed name order or titles used as given names.