Conversation Audit Trail Prompt for Dropped Items

This prompt is designed for compliance and quality assurance teams that need a structured, timestamped audit trail of every question, commitment, and action item within a conversation transcript. It is not a real-time tracking system but a post-hoc analysis tool. Use it when you need to prove to an auditor or a quality reviewer that no user request was silently dropped, every commitment was tracked, and every action item has a clear disposition. The output is designed to be both human-reviewable and machine-parsable for ingestion into compliance systems.

The ideal user is a QA analyst, compliance officer, or operations lead reviewing closed conversations—support tickets, sales calls, or internal copilot sessions—where regulatory or contractual obligations require evidence of complete handling. Required context includes the full conversation transcript, a timestamp format specification, and a defined taxonomy of item types (e.g., question, commitment, action_item). The prompt expects a clear [OUTPUT_SCHEMA] that maps each item to a resolution status (resolved, partially_resolved, dropped, deferred, pending_external) with supporting evidence quotes from the transcript. Without this schema, the model will produce inconsistent, non-auditable output.

Do not use this prompt for live agent decision-making; it is an offline audit and evidence-generation tool. It is not suitable for real-time turn-by-turn tracking, where a state machine or structured middleware is more appropriate. Avoid this prompt when the transcript contains highly ambiguous or implicit commitments that require subjective interpretation—the model will hallucinate dispositions rather than flagging ambiguity. For high-risk domains (finance, healthcare, legal), always route the output through human review before it becomes part of an official audit record. The next section provides the copy-ready prompt template you can adapt to your transcript format and compliance requirements.

This prompt template is the core instruction set for transforming a raw conversation transcript into a machine-readable compliance artifact. It is designed to be directly copied into your prompt management system or orchestration code. The template uses square-bracket placeholders for all dynamic inputs, ensuring you can wire it into a production harness without manual text editing. The primary goal is to produce a single JSON object that a downstream compliance system or human reviewer can parse to understand exactly what was promised, asked, and resolved—and, critically, what was dropped.

textCopy
You are an expert conversation auditor. Your task is to analyze the provided conversation transcript and produce a structured audit trail. Your output must be a single JSON object conforming to the specified schema.

### INPUT
[CONVERSATION_TRANSCRIPT]

### OUTPUT SCHEMA
{
  "audit_trail": [
    {
      "item_id": "string (unique identifier, e.g., 'item-001')",
      "timestamp": "string (ISO 8601 timestamp of the turn where the item originated)",
      "turn_number": "integer (the index of the turn in the transcript, starting from 1)",
      "speaker": "string (the role of the speaker who raised the item, e.g., 'user', 'assistant')",
      "type": "string (enum: 'question', 'commitment', 'action_item')",
      "description": "string (a concise, verbatim-like summary of the item)",
      "status": "string (enum: 'resolved', 'explicitly_deferred', 'dropped')",
      "resolution_evidence": "string or null (if resolved, quote the turn and speaker that resolved it; otherwise null)",
      "dropped_flag": "boolean (true if the item was raised but never resolved or explicitly deferred)",
      "severity": "string (enum: 'low', 'medium', 'high', 'critical' - assessed based on potential compliance, safety, or user-experience impact)"
    }
  ],
  "summary": {
    "total_items": "integer",
    "resolved_items": "integer",
    "deferred_items": "integer",
    "dropped_items": "integer",
    "high_severity_dropped_items": "integer"
  }
}

### CONSTRAINTS
- Extract every explicit question, commitment (e.g., 'I will send you...', 'Let me check on that'), and action item (e.g., 'Please review the document').
- Do not invent items that are not present in the transcript.
- A 'dropped' item is one that was raised but never addressed again in the conversation. An item is 'explicitly_deferred' only if a speaker clearly states it will be handled later.
- For resolution evidence, provide the exact quote from the transcript that closes the loop.
- If an item is dropped, the 'resolution_evidence' field must be `null` and the 'dropped_flag' must be `true`.
- The output must be a single, valid JSON object with no additional text or markdown formatting.

To adapt this template, replace the [CONVERSATION_TRANSCRIPT] placeholder with your full dialogue text, ensuring speaker labels and timestamps are clearly delineated. The schema is intentionally strict to enable direct ingestion by a database or a compliance dashboard. Before deploying, test the prompt with transcripts containing edge cases: a question asked and immediately answered, a commitment made in the last turn, and a conversation with no actionable items at all. The most common failure mode is the model hallucinating a resolution for a dropped item; your evaluation harness must explicitly check that any item with a dropped_flag of true has a null resolution_evidence field. For high-stakes compliance workflows, always route outputs where high_severity_dropped_items > 0 for immediate human review.

The Conversation Audit Trail Prompt is not a real-time chat component; it is a post-hoc analysis tool designed to run after a conversation concludes or at defined checkpoints. The primary integration point is an asynchronous processing pipeline that triggers on session close, ticket resolution, or a scheduled batch window. The harness must provide the full transcript as [INPUT], a structured [OUTPUT_SCHEMA] defining the expected JSON fields (e.g., item_id, type, timestamp, resolution_status, evidence), and a [CONSTRAINTS] block specifying the compliance standard or review policy. Because the output is intended for human review and compliance systems, the harness must treat the model's output as a draft that requires deterministic post-processing before it becomes an official record.

To wire this into an application, wrap the prompt in a function that accepts a session object and returns an audit trail. The function should first validate the input transcript, ensuring it contains turn-level metadata (speaker, timestamp, message body) rather than a raw string. After calling the LLM, apply a strict JSON schema validator against the [OUTPUT_SCHEMA]. Any item that fails validation—missing required fields, invalid enum values for resolution_status, or evidence strings that don't appear in the source transcript—should be flagged for human review rather than silently dropped. Implement a retry loop with a maximum of two attempts: if validation fails, re-invoke the model with the validation errors appended to the prompt as additional [CONSTRAINTS]. If the second attempt also fails, log the failure, attach the raw model output, and escalate the entire session to a manual review queue. For model choice, prefer a model with strong instruction-following and long-context handling (e.g., Claude 3.5 Sonnet or GPT-4o) because the prompt requires precise extraction across potentially thousands of tokens of dialogue.

The most critical production safeguard is evidence grounding verification. The prompt instructs the model to quote evidence from the transcript, but the harness must not trust those quotes. Implement a post-processing step that performs a substring search for each evidence string against the original transcript. If an evidence quote cannot be located (allowing for minor whitespace normalization), the item should be flagged with a GROUNDING_FAILURE status and routed for human review. Additionally, implement a coverage check: count the total number of user questions and agent commitment statements detected by a simpler, high-recall classifier, and compare against the audit trail's item count. A significant discrepancy suggests the model missed items and should trigger a re-run with a lower temperature or an escalation to a human auditor. Log every run with the prompt version, model ID, input token count, validation pass/fail status, grounding failure count, and human review flags for observability. Never automatically close a compliance-relevant item based solely on the model's resolution_status field without a human-in-the-loop confirmation step when the [RISK_LEVEL] is set to high.