Support Ticket Trace Event Mapping Prompt

This prompt is designed for support engineers and AI operations teams who need to connect a user-submitted support ticket to the specific production trace events that represent the user's session. The core job-to-be-done is automating the first mile of incident diagnosis: given a ticket containing a user complaint, a timestamp, and a user identifier, the prompt must identify the correct trace, extract the relevant spans, and produce a structured mapping that links each ticket field to trace evidence. This is not a general-purpose trace explorer or a session replay tool; it is a targeted diagnostic prompt that answers the question, 'What happened in the system when this user had this problem?'

Use this prompt when you have a support ticket with at least a user ID and a time window, and you have access to a trace store or observability backend that can retrieve traces by those keys. The prompt assumes that the trace data has already been fetched and provided as input—it does not perform the retrieval itself. It is most effective when the ticket contains a clear description of the user's complaint, because the mapping logic uses that description to rank trace events by relevance to the reported issue. Do not use this prompt when the ticket is a vague 'it's broken' report with no user identifier or timestamp; in that case, you need a session reconstruction or anomaly detection prompt first. Also avoid this prompt when the trace data is incomplete or spans are missing, because the confidence scoring will degrade and the output will be unreliable without manual review.

The ideal reader is a support engineer or AI SRE who understands the structure of production traces—spans, events, tool calls, model responses—but does not want to manually scan hundreds of trace events to find the one that explains a customer complaint. The prompt produces a structured JSON output with a confidence score per mapping, explicit trace evidence excerpts, and a flag for tickets that require manual trace review. This output is designed to be consumed by a downstream ticketing system or an internal dashboard, not read raw by a human. Before deploying this prompt into an automated pipeline, you must implement validation checks for correct ticket-to-trace linking and false-positive attribution, and you must define a human review threshold for low-confidence mappings. The next section provides the copy-ready prompt template you can adapt to your trace schema and ticket format.

This prompt template is designed to be copied directly into your AI harness and adapted for your specific ticketing and observability systems. It accepts a support ticket payload and a user session trace, then produces a structured mapping that links each ticket field to the most relevant trace spans. The output includes evidence excerpts pulled directly from the trace, a confidence score for each mapping, and a flag indicating whether the ticket requires manual trace review by a human operator. Use this template as the foundation for an automated triage pipeline that reduces the time support engineers spend hunting through raw traces.

Below is the copy-ready prompt template. Replace each square-bracket placeholder with your actual data, schemas, and constraints before wiring it into your application. The [TICKET_PAYLOAD] should contain the full support ticket as JSON or structured text. The [TRACE_DATA] should contain the user's session trace in your observability format (e.g., OpenTelemetry spans, LangSmith runs, or custom trace events). The [OUTPUT_SCHEMA] defines the exact JSON structure you expect back, and [CONFIDENCE_THRESHOLD] sets the minimum score for automated acceptance. Tickets below this threshold should be routed for manual review.

textCopy
You are a support trace analyst. Your task is to map each field in a support ticket to the most relevant trace events from the user's session.

## INPUT

**Support Ticket:**
[TICKET_PAYLOAD]

**User Session Trace:**
[TRACE_DATA]

## OUTPUT SCHEMA

Return a valid JSON object matching this schema exactly:

[OUTPUT_SCHEMA]

## MAPPING RULES

1. For each field in the support ticket, identify the trace span or event that best explains or correlates with the reported issue.
2. Extract a direct evidence excerpt from the trace that supports the mapping. Do not paraphrase or summarize without quoting.
3. Assign a confidence score between 0.0 and 1.0 for each mapping, where:
   - 0.9-1.0: Direct, unambiguous match with clear trace evidence
   - 0.7-0.89: Strong correlation but minor ambiguity
   - 0.5-0.69: Plausible match but requires verification
   - Below 0.5: Speculative; flag for manual review
4. If no relevant trace event exists for a ticket field, set the mapping to null and confidence to 0.0 with a note explaining the gap.
5. Flag the entire ticket for manual review if any field has confidence below [CONFIDENCE_THRESHOLD] or if the trace appears incomplete.

## CONSTRAINTS

- Do not invent trace events that do not exist in the provided data.
- Do not map a ticket field to a trace event unless you can cite specific evidence from the trace.
- If the trace contains sensitive data (PII, credentials, tokens), do not include it in evidence excerpts. Note redactions instead.
- If the ticket references a time range, prioritize trace events within that window.
- If multiple trace spans could match a ticket field, select the one with the strongest evidence and note alternatives in a `candidates` array.

## EXAMPLES

[EXAMPLES]

## RISK LEVEL

[RISK_LEVEL]

After copying this template, adapt the [OUTPUT_SCHEMA] to match your internal data contracts. At minimum, the schema should include a mappings array where each element contains the ticket field name, the matched trace span ID, the evidence excerpt, the confidence score, and a requires_review boolean. If your ticketing system uses custom fields or priority levels, extend the schema accordingly. The [EXAMPLES] placeholder should be populated with 2-3 few-shot examples that demonstrate correct mappings for your specific ticket types and trace formats. For high-risk workflows where incorrect trace attribution could lead to misdirected fixes or missed SLAs, set [RISK_LEVEL] to high and ensure the output is routed through a human approval queue before any automated action is taken. Test this prompt against a golden dataset of known ticket-to-trace mappings and measure precision and recall before deploying to production.

This prompt is designed to be called programmatically as part of an automated support triage pipeline, not as a one-off chat interaction. When a support ticket is created, the application should fetch the user's session ID from the ticket metadata, query your observability platform (e.g., LangSmith, Arize, Datadog LLM Observability) for the full trace, and inject the ticket fields and trace spans into the prompt template. The model's output—a structured mapping with confidence scores—should be written back to the ticket as an internal note and used to route the ticket or pre-populate a root-cause analysis.

Validation and retries: The prompt requests a specific JSON schema. Your application must validate the response against that schema immediately. If the model returns malformed JSON, missing required fields, or a confidence score that doesn't match the evidence excerpts, retry once with the validation error message appended to the prompt. If the second attempt fails, flag the ticket for manual trace review and log the raw response for debugging. Do not silently accept a broken mapping.

Human-in-the-loop gating: The manual_review_required boolean in the output schema is your primary escalation signal. Any ticket where this flag is true or where the confidence_score falls below a configurable threshold (start with 0.7) should be routed to a human reviewer queue. The reviewer sees the original ticket, the trace spans, and the model's proposed mapping, and can confirm or correct the attribution before the ticket proceeds. This gate is critical because incorrect trace-to-ticket linking can send engineering teams down the wrong diagnostic path.

Model choice and context window: Use a model with strong JSON mode and long-context handling (e.g., GPT-4o, Claude 3.5 Sonnet). Trace spans can be verbose, so truncate individual span bodies to the first 500 tokens and limit the total number of spans to the 50 most recent before the ticket timestamp. If the user session contains more spans, include a [TRUNCATED] marker and a count of omitted spans so the model can factor incompleteness into its confidence score.

Logging and audit trail: Log every mapping request and response as a structured event with the ticket ID, trace ID, model version, prompt version, confidence score, and manual review decision. This audit trail is essential for measuring the prompt's accuracy over time and for defending support routing decisions during incident postmortems. Use these logs to build an eval dataset: sample 100 tickets weekly, have a human reviewer label the correct trace-to-ticket mapping, and compare against the model's output to track precision and recall.