Dialogue State Diff Generation Prompt

This prompt is designed for audit, debugging, and compliance systems that need to explain why a conversational AI's internal state changed between turns. The core job-to-be-done is generating a human- and machine-readable diff from two consecutive dialogue state snapshots. The ideal user is an AI engineer or platform developer building observability into a multi-turn assistant, a compliance officer reviewing a decision trace, or a debugging tool that surfaces state anomalies. The required context is a pair of structured state objects (the 'before' and 'after' states) and the specific user utterance that triggered the transition. Without all three inputs, the diff will be speculative.

Do not use this prompt for real-time state tracking or for generating the state objects themselves. It is a post-hoc analysis tool, not a state manager. It is also not a replacement for a deterministic state machine; use it when the state transition logic is complex, model-driven, or requires natural-language explanations for human review. The prompt is most valuable when state changes are non-obvious—for example, when a user's clarification silently overwrites a previously confirmed slot, or when a topic shift causes a cascade of intent and entity updates that a simple JSON patch would not explain. In high-compliance environments, the output should be treated as a draft requiring human approval before being committed to an official audit trail.

Before wiring this into a production pipeline, ensure your upstream state tracking system reliably captures the before and after snapshots at the correct granularity. A common failure mode is feeding the prompt incomplete state objects that lack the fields the model needs to explain the change. The next section provides the exact prompt template and placeholder definitions. After adapting it, proceed to the implementation harness to add validation, retries, and logging.

This prompt template is designed for audit, debugging, and compliance systems that need to track dialogue state evolution across turns. It takes two consecutive state snapshots and the user utterance that occurred between them, then produces a human- and machine-readable diff. The output is structured for both developer debugging and automated compliance trace generation. Use this when you need to explain state transitions, not just record them.

textCopy
You are a dialogue state auditor. Your task is to compare two consecutive dialogue state snapshots and explain what changed, why it changed, and which user utterance triggered the change.

## INPUTS

### Previous State (before the user turn)
```json
[PREVIOUS_STATE]

Current State (after the user turn)

jsonCopy
[CURRENT_STATE]

User Utterance (the turn that occurred between the two states)

textCopy
[USER_UTTERANCE]

State Schema Definition (optional, for field interpretation)

jsonCopy
[STATE_SCHEMA]

OUTPUT SCHEMA

Return a JSON object with the following structure:

jsonCopy
{
  "diff_summary": "One-sentence summary of what changed",
  "changes": [
    {
      "field_path": "dot.notation.path.to.changed.field",
      "change_type": "added | removed | modified | confirmed | retracted",
      "previous_value": null,
      "current_value": null,
      "trigger_evidence": "Specific span from the user utterance that caused this change",
      "rationale": "Explanation of why the system made this change",
      "confidence": "high | medium | low"
    }
  ],
  "unchanged_fields": ["list of field paths that were expected to change but did not"],
  "anomalies": [
    {
      "type": "unexpected_change | missing_expected_change | contradiction | hallucination_risk",
      "field_path": "dot.notation.path",
      "description": "What looks wrong and why",
      "severity": "critical | warning | info"
    }
  ],
  "trigger_utterance_span": "The exact text from the user utterance most responsible for the state changes"
}

CONSTRAINTS

1. Only report changes that actually occurred between the two snapshots. Do not invent changes.
2. For each change, cite the specific span from [USER_UTTERANCE] that triggered it.
3. If a field was expected to change based on the utterance but did not, list it under unchanged_fields.
4. Flag anomalies where the state change appears inconsistent with the utterance, the schema, or the previous state.
5. Use change_type: "confirmed" when a previously ambiguous or unverified field becomes confirmed.
6. Use change_type: "retracted" when a previously set field is removed or marked invalid.
7. If no changes occurred, return an empty changes array and explain why in diff_summary.
8. Do not include fields that are identical between the two snapshots unless they appear in unchanged_fields.
9. Maintain valid JSON syntax. Escape any internal quotes.

EXAMPLES

[EXAMPLES]

RISK LEVEL

[RISK_LEVEL]

To adapt this template, replace the square-bracket placeholders with your actual data. [PREVIOUS_STATE] and [CURRENT_STATE] should be serialized JSON objects representing your dialogue state at two consecutive turns. [USER_UTTERANCE] is the raw text of the user message that occurred between those state snapshots. [STATE_SCHEMA] is optional but strongly recommended—it helps the model interpret field semantics and detect anomalies. [EXAMPLES] should contain 1-3 few-shot examples of correct diffs for your specific state schema. [RISK_LEVEL] should be set to "high" for compliance or audit use cases, which will cause the model to be more conservative in its change detection and more thorough in its anomaly flagging. For debugging use cases, set it to "medium" to balance thoroughness with noise reduction.

This prompt is designed to operate as a deterministic, post-hoc analysis step, not a real-time user-facing feature. It should be triggered after a state management system commits a new dialogue state snapshot. The harness must provide the prompt with two consecutive, timestamped state snapshots and the exact user utterance that occurred between them. The primary consumers are developer debugging tools, compliance audit trails, and automated regression test suites that need to verify state transitions are correct and explainable.

The implementation should wrap the LLM call in a strict validation layer. Before the diff is stored or displayed, validate that the output JSON conforms to the expected schema: a change_type field from a controlled vocabulary (added, modified, deleted, confirmed, corrected), a trigger_utterance field that matches the provided user input, and a rationale string. Reject any output that references slots or entities not present in either the previous_state or current_state inputs. For high-compliance use cases, log the raw prompt, the model response, and the validation result to an append-only audit store before the diff is surfaced to any UI.

Model choice matters for cost and latency, not just quality. Since this is an offline, batch-compatible task, prefer a smaller, cheaper, and faster model (e.g., a fine-tuned lightweight model or a fast inference endpoint) if your state schema is stable. Run a calibration suite weekly: feed the prompt a set of 50-100 hand-labeled state transitions and measure exact-match accuracy on the change_type field and semantic similarity of the rationale against a reference. If accuracy drops below a threshold (e.g., 95%), escalate to a stronger model or trigger a prompt review. Avoid running this on every turn in a high-throughput chat product without sampling; instead, run it on a percentage of traffic for monitoring or on-demand for specific sessions under review.