Survey Response Text to Structured Answers Prompt Template

This playbook is for analytics engineers and data pipeline operators who receive raw, free-text survey responses and need to convert them into structured, analyzable records. Use this prompt when a model has already generated a narrative answer or when you are processing verbatim open-ended responses from a survey platform. The prompt produces typed records with question mapping, answer normalization, sentiment scores, and theme tags. It is designed for post-collection repair and normalization, not for generating survey responses. This workflow assumes you have already extracted the raw text and now need to impose structure for downstream analytics, dashboards, or statistical coding.

The ideal user has a batch of free-text responses that map to known survey questions but lack consistent formatting. For example, a verbatim response like 'I was really frustrated with the checkout process, it took forever to load' needs to become a record with a normalized answer, a sentiment score of -0.7, and a theme tag of 'UX/Performance'. This prompt is not a replacement for a survey platform's native export. Do not use it when you need real-time response generation, when the survey instrument itself is unknown, or when the raw text contains multi-turn conversational threads that require dialogue state tracking. The prompt assumes a single response per input and a known question catalog.

Before using this prompt, ensure you have a defined question catalog with unique IDs and a controlled vocabulary for theme tags. The prompt's value comes from its ability to simulate inter-rater reliability by producing consistent coding across thousands of responses, but it requires a clear target schema. If your survey includes skip logic or branching, pre-process the raw text to associate each response with its specific question ID before calling this prompt. For high-stakes analytics (e.g., regulatory reporting or academic research), always run the eval harness described in the implementation section to measure coding consistency and flag low-confidence normalizations for human review.

This template is the core instruction set for converting a batch of free-text survey responses into a structured JSON array. It is designed to be copied directly into your prompt management system, API call, or evaluation harness. The prompt instructs the model to map each response to its corresponding question, normalize the answer, assign a sentiment score, and tag relevant themes. Before using this template, you must have your survey questions, the raw response text, and a defined set of acceptable theme tags ready to insert into the placeholders.

textCopy
You are an analytics engineer converting free-text survey responses into structured, coded records. Your task is to process the provided survey responses and output a single, valid JSON array of answer objects. Do not include any text outside the JSON array.

## SURVEY QUESTIONS
[QUESTION_LIST]

## RAW SURVEY RESPONSES
[RAW_RESPONSES]

## OUTPUT SCHEMA
Output a JSON array where each object has the following keys:
- "response_id": A unique identifier from the input, or a generated UUID if none exists.
- "question_id": The identifier of the question this response answers, mapped from [QUESTION_LIST].
- "question_text": The exact text of the question being answered.
- "raw_answer": The original, unedited answer text.
- "normalized_answer": A cleaned and standardized version of the answer (e.g., expand abbreviations, correct obvious typos, standardize casing).
- "sentiment_score": A string, one of "positive", "neutral", "negative", or "mixed", based on the sentiment expressed in the answer.
- "theme_tags": An array of strings from the approved list in [THEME_TAXONOMY] that apply to this answer. If no themes match, use an empty array.
- "confidence": A number between 0.0 and 1.0 indicating your confidence in the accuracy of the coding for this specific response.

## THEME TAXONOMY
[THEME_TAXONOMY]

## CONSTRAINTS
- Map each response to the correct question using the context and any provided IDs.
- Do not invent new theme tags; use only those provided in [THEME_TAXONOMY].
- If an answer is nonsensical, empty, or a non-answer (e.g., "asdf", "no comment"), set the "normalized_answer" to null, "sentiment_score" to "neutral", and "theme_tags" to an empty array.
- Ensure the output is strictly valid JSON with no trailing commas.

To adapt this template for your pipeline, replace the square-bracket placeholders with your specific data. [QUESTION_LIST] should be a structured list of your survey questions with their IDs, which the model uses for mapping. [RAW_RESPONSES] is the batch of free-text answers you need to process. [THEME_TAXONOMY] must be an exhaustive list of allowed theme strings; the model is constrained to this list to ensure coding consistency. For high-stakes analysis, such as employee engagement or clinical surveys, you should add a [RISK_LEVEL] constraint that triggers a lower confidence score or a flag for human review when sentiment is strongly negative or themes indicate a critical event. After running this prompt, always validate the output JSON against the defined schema and use an LLM-as-judge eval to check inter-rater reliability against a human-coded golden dataset before trusting the results in a dashboard.

This prompt is designed to sit inside a post-extraction normalization pipeline, not as a standalone chat interface. The typical flow begins when a raw survey response—often a block of free text, a transcript snippet, or a semi-structured markdown field—fails to parse into your target analytics schema. The application layer should first attempt a direct structured output call. If that call returns a parse_error, a schema_mismatch, or a confidence score below your threshold, route the raw text and the failed parse metadata into this repair prompt as the [RAW_SURVEY_TEXT] and [TARGET_SCHEMA] inputs. The [QUESTION_CONTEXT] placeholder should be populated with the original survey question text, the expected answer type (single-select, multi-select, Likert scale, open-ended), and any valid category codes from your codebook. This context is critical for the model to perform accurate answer normalization and theme tagging rather than inventing its own categories.

The application harness must enforce a strict validation loop around the model's output. After the prompt returns a JSON payload, validate it against the expected schema immediately: check that question_id matches the input, normalized_answer is not null for required questions, sentiment_score is a float between -1.0 and 1.0, and theme_tags contains only strings from your approved taxonomy. If validation fails, do not silently drop the record. Implement a retry strategy with a maximum of two additional attempts, feeding the validation error messages back into the [PREVIOUS_ERRORS] placeholder on the next call. After three total failures, route the record to a human review queue with the raw text, the failed outputs, and the validator error log attached. For high-volume pipelines, use a model that supports structured output guarantees (like GPT-4o with response_format or Claude with tool use) for the initial attempt, and reserve this free-text repair prompt for the fallback path only. This keeps latency and cost low for the 80-90% of responses that parse correctly on the first try.

Logging and observability are non-negotiable for this workflow. Every invocation should log the survey_id, response_id, attempt_number, model_used, latency_ms, validation_passed (boolean), and a hash of the raw input text. This lets you track repair rates over time, identify survey questions that consistently produce unparseable responses, and measure inter-rater reliability by comparing the model's coded categories against a human-coded sample. For the inter-rater reliability simulation mentioned in the topic description, run a weekly batch job that pulls 100 randomly selected repaired records, sends them to a second model call with a different temperature setting, and computes Cohen's kappa between the two sets of theme_tags and normalized_answer fields. Flag any question where kappa drops below 0.7 for prompt or codebook review. Do not ship this prompt without building a dashboard that shows repair volume, validation pass rates, and human-approval queue depth—these metrics will tell you whether the prompt is actually reducing manual work or just moving it downstream.