Turn-Level State Change Audit Record Prompt

Use this prompt when you need a machine-readable, turn-by-turn audit trail of state mutations inside a compliance-sensitive chat system. The primary job-to-be-done is generating a structured JSON record that answers three questions after every user or assistant turn: what state field changed, why it changed, and what evidence justified the change. This is essential for support operations teams in regulated industries (finance, healthcare, insurance) where auditors require proof that the assistant did not silently drop a customer commitment, alter a policy interpretation, or overwrite a verified fact without a traceable reason. The ideal user is an AI engineer or compliance architect integrating this prompt into a stateful chat pipeline that already maintains a prior state object, a conversation history, and a set of system policies.

This prompt is not a replacement for full session snapshots or human-readable decision narratives. It produces a focused, machine-ingestible change record—not a complete state dump. You must pair it with the Session State Snapshot Generation Prompt for full serialization and the Conversation Decision Trace Prompt for human review. Do not use this prompt when you lack a structured prior state object to diff against; it will hallucinate changes if forced to infer state from raw text alone. The prompt assumes you have access to the current turn, the prior state object, and any relevant policy documents. It works best when state fields are typed (e.g., customer_intent, verified_identity, payment_method) and when policies are explicit enough to cite by ID or rule reference.

Before deploying this prompt, define the state schema you will audit. The prompt's output includes changed_fields, unchanged_fields, and justification blocks, each referencing field names and evidence sources. If your state object is a flat dictionary of 50 keys, the audit record will be noisy and expensive. Instead, scope the audit to high-risk fields: those that affect downstream actions, compliance obligations, or user-facing commitments. For each field, decide whether a change requires a policy citation, a user utterance quote, or a tool-return reference. This constraint prevents the model from generating vague justifications like 'updated based on conversation context.' The next step after reading this section is to review the prompt template and adapt the [STATE_SCHEMA] and [POLICY_DOCUMENTS] placeholders to your system's actual schema and rules. Avoid using this prompt on every turn for low-risk fields; reserve it for state mutations that matter to auditors.

This prompt template generates a turn-level state change audit record for compliance and support operations teams building auditable chat systems. It is designed to be called after every user or assistant turn in a conversation, producing a machine-readable JSON object that captures what changed in the conversation state, the evidence that justified the change, and a timestamp-ordered trace suitable for downstream review or storage. The prompt assumes you have access to the current turn's input, the prior conversation state, and any relevant system policies or retrieved evidence. Replace each square-bracket placeholder with your application's actual data before sending the prompt to the model.

textCopy
You are an audit record generator for a regulated conversation system. Your task is to produce a structured JSON record that documents every state change that occurred during the most recent conversation turn. You must cite specific evidence for each change and maintain strict timestamp ordering.

## INPUT
- Current turn speaker: [SPEAKER_ROLE]
- Current turn content: [TURN_CONTENT]
- Prior conversation state (JSON): [PRIOR_STATE]
- Active system policies (JSON): [ACTIVE_POLICIES]
- Retrieved evidence used this turn (JSON array, may be empty): [RETRIEVED_EVIDENCE]
- Conversation metadata: [CONVERSATION_METADATA]

## OUTPUT SCHEMA
Return ONLY a valid JSON object with this exact structure:
{
  "audit_record": {
    "record_id": "string, unique identifier for this audit record",
    "conversation_id": "string, from conversation metadata",
    "turn_number": "integer, from conversation metadata",
    "speaker": "string, user or assistant",
    "timestamp": "string, ISO 8601 UTC",
    "state_changes": [
      {
        "change_id": "string, unique within this record",
        "state_path": "string, dot-notation path to the changed field in prior state",
        "change_type": "string, one of: added, modified, removed, confirmed_unchanged",
        "prior_value": "any, the value before this turn, or null if added",
        "new_value": "any, the value after this turn, or null if removed",
        "evidence_source": "string, one of: user_input, retrieved_document, policy_rule, inference, tool_output, explicit_user_correction",
        "evidence_citation": "string, specific quote or reference from the evidence source",
        "confidence": "string, one of: high, medium, low",
        "justification": "string, brief explanation of why this change was made"
      }
    ],
    "unchanged_state_confirmed": [
      {
        "state_path": "string, dot-notation path",
        "current_value": "any",
        "confirmation_reason": "string, why this was checked and confirmed unchanged"
      }
    ],
    "pending_items_updated": [
      {
        "item_id": "string",
        "status": "string, one of: created, resolved, deferred, escalated, cancelled",
        "description": "string",
        "evidence": "string"
      }
    ],
    "policy_evaluations": [
      {
        "policy_id": "string, from active policies",
        "triggered": "boolean",
        "action_taken": "string or null",
        "evidence": "string"
      }
    ],
    "risks_flagged": [
      {
        "risk_type": "string, e.g., stale_context, policy_violation, missing_evidence, contradiction",
        "severity": "string, one of: low, medium, high, critical",
        "description": "string",
        "affected_state_paths": ["string"]
      }
    ],
    "completeness_check": {
      "all_input_fields_processed": "boolean",
      "all_prior_state_fields_reviewed": "boolean",
      "missing_evidence_fields": ["string"],
      "notes": "string"
    }
  }
}

## CONSTRAINTS
- Every state change MUST include a specific evidence citation. Do not cite "model inference" unless no other source exists and you mark confidence as "low".
- If the user explicitly corrects a prior assistant claim, you MUST record a "modified" change with evidence_source "explicit_user_correction" and confidence "high".
- Timestamps in state_changes must be monotonically increasing within the turn.
- If retrieved evidence has a timestamp older than [STALENESS_THRESHOLD_HOURS] hours from the current turn, flag it in risks_flagged with risk_type "stale_context".
- Do not invent state paths. Only reference paths that exist in PRIOR_STATE or are explicitly created this turn.
- If no state changes occurred, return an empty state_changes array but still populate completeness_check.
- Mark confidence as "low" for any change based solely on inference without direct evidence.

## RISK LEVEL: [RISK_LEVEL]
- If RISK_LEVEL is "high" or "critical", you MUST populate risks_flagged for any change with confidence "low" or "medium".
- If RISK_LEVEL is "critical", you MUST require human review before finalizing any state change with confidence below "high". Indicate this in completeness_check.notes.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

Generate the audit record now. Return ONLY the JSON object, no other text.

To adapt this template for your application, replace the placeholders with real data at runtime. [PRIOR_STATE] should be the serialized conversation state object from your state management layer, typically a JSON blob tracking slots, intents, pending actions, and policy flags. [RETRIEVED_EVIDENCE] should include the full retrieved document objects with their timestamps and source identifiers, not just the text snippets, so the model can evaluate staleness. [ACTIVE_POLICIES] must include policy IDs and trigger conditions so the model can populate policy_evaluations accurately. For high-risk deployments, set [RISK_LEVEL] to "high" or "critical" and ensure your application layer enforces the human review requirement before persisting any state changes the model flags as low-confidence. The [FEW_SHOT_EXAMPLES] placeholder should contain 2-3 example input-output pairs showing correct audit records for common scenarios: a simple slot fill, a user correction, and a stale-evidence flag. Without examples, the model may hallucinate state paths or misclassify evidence sources.

After receiving the model's output, validate the JSON structure against the schema before persisting the audit record. Run eval checks for completeness: confirm that every field in [PRIOR_STATE] appears in either state_changes or unchanged_state_confirmed, verify that all evidence citations reference actual sources provided in [RETRIEVED_EVIDENCE] or the turn content, and check that timestamps are monotonically increasing. If the completeness_check.all_input_fields_processed or all_prior_state_fields_reviewed fields are false, or if missing_evidence_fields is non-empty, log a warning and consider re-running the prompt with more explicit instructions. Never persist an audit record that fails schema validation or contains hallucinated evidence citations.

The Turn-Level State Change Audit Record Prompt is designed to be called after every assistant turn in a conversation pipeline. It should not be called on user turns in isolation—the prompt expects both the user input and the assistant's response to determine what state changed and why. Wire this prompt as a post-processing step in your turn handler, after the assistant response is generated but before the response is sent to the user. This ensures the audit record is captured even if downstream delivery fails. The prompt is stateless by design: it receives the prior state snapshot, the current turn pair, and the system policies as input, and produces a structured change record without relying on any persistent memory of its own.

Validation and retry logic is critical because audit records are downstream dependencies for compliance review, debugging, and state reconstruction. After the prompt returns, validate the output against a JSON schema that enforces: (1) required fields turn_id, timestamp, changed_fields, evidence, and justification; (2) timestamp ordering relative to the prior turn; (3) every entry in changed_fields must reference a field that exists in either the prior or new state snapshot; and (4) evidence must cite specific turn content or policy rules, not generic statements. If validation fails, retry once with the validation errors appended to the prompt as [CONSTRAINTS] feedback. If the retry also fails, log the raw output, flag the turn for human review, and do not block the conversation—audit gaps are better than dropped user experiences. For high-risk domains such as healthcare or finance, route validation failures to a human review queue immediately rather than retrying.

Model choice and latency budgeting matter here. This prompt is not latency-sensitive in the user-facing path because it runs after the assistant response is generated. Use a model with strong instruction-following and JSON output reliability—GPT-4o, Claude 3.5 Sonnet, or equivalent. If cost is a concern, you can run this prompt on a cheaper model (GPT-4o-mini, Claude Haiku) for low-risk conversation types, but validate more aggressively and increase the human-review sampling rate. Logging: store every audit record—both passing and failing—in an append-only audit log with the prompt version, model identifier, raw prompt, raw response, validation result, and any human review decisions. This log becomes your evidence trail for compliance audits and your debugging dataset for prompt improvement. Tool use: this prompt does not call external tools, but the output changed_fields should be consumable by your state management layer to update the canonical session state. Never update canonical state directly from the audit record without validation—the audit record describes what changed, but your state manager owns the authoritative update.

Human review integration should be designed as a sampling gate, not a blocking gate. For most turns, the validated audit record is written to the log and the conversation continues. Configure a sampling rule: 100% of turns where validation failed, 100% of turns in high-risk conversation categories, and X% of all other turns (start with 5-10% and adjust based on your compliance requirements and review capacity). The review interface should display the prior state, the turn transcript, the generated audit record, and any validation warnings side by side. Reviewers should be able to accept, edit, or reject the audit record, and their decisions should be logged with reviewer identity and timestamp. Avoid building a system where human review is required before the conversation can continue—this creates unacceptable latency for users and will be bypassed in practice.