Record Update Field Comparison Prompt

This prompt is designed for the postcondition verification stage of an agent pipeline, after a mutation step claims success but before the next step consumes the updated record. It solves a specific operational problem: agents that modify existing records can silently corrupt data by altering fields they were not supposed to touch, dropping fields entirely, or letting system-managed columns like updated_at mask real data loss. The prompt takes two snapshots—a pre-update state and a post-update state—and produces a field-level diff that separates intended changes from unintended ones, with explicit rollback suggestions when corruption is detected.

The ideal user is an agent runtime developer or platform engineer building validation layers into autonomous workflows. You should wire this prompt into a harness that captures the record state before the mutation step executes, then feeds both snapshots into the prompt after the mutation step returns. The prompt expects a declared list of intended changes as part of its input, which typically comes from the agent's own plan or tool call arguments. Without that declared-intent list, the prompt can still produce a raw diff, but it cannot distinguish between legitimate updates and silent corruption. Use this prompt when the cost of undetected field corruption is high—financial records, compliance data, user profile mutations, or configuration changes that affect downstream system behavior.

Do not use this prompt for schema validation, type checking, or output contract enforcement. Those concerns belong to separate validation prompts that check structure rather than semantic correctness. Do not use it when the record has hundreds of fields and the intended change list is unknown; the prompt will produce noisy diffs that are expensive to review and easy to ignore. In high-throughput pipelines where latency budgets are tight, consider sampling-based verification or deferring full field comparison to an asynchronous audit path. For regulated domains, always log the diff output alongside the agent's action trail and require human review when unintended changes are flagged with severity above a defined threshold.

The following prompt is designed to be pasted directly into your agent's postcondition validation step. It instructs the model to perform a strict field-level comparison between a pre-update and post-update record snapshot. The goal is to confirm that only the fields the agent intended to modify were actually changed, and that no unintended side effects—such as overwritten audit fields, timestamp noise, or cascading defaults—corrupted the record. Replace every square-bracket placeholder with the actual values from your application context before sending this prompt to the model.

textCopy
You are a record integrity validator for an autonomous agent system. Your job is to compare a record's state before and after an agent-performed update and determine whether only the intended fields were modified.

# INPUT
- Pre-Update Record: [PRE_UPDATE_RECORD_JSON]
- Post-Update Record: [POST_UPDATE_RECORD_JSON]
- Intended Modifications: [INTENDED_MODIFICATIONS_LIST]
- Ignored Fields (e.g., timestamps, audit fields): [IGNORED_FIELDS_LIST]

# TASK
1. Compute the field-level diff between the pre-update and post-update records.
2. Classify each changed field into one of three categories:
   - **INTENDED**: The field is in the Intended Modifications list and its new value matches the intended change.
   - **UNINTENDED**: The field changed but is NOT in the Intended Modifications list and is NOT in the Ignored Fields list.
   - **NOISE**: The field changed but is in the Ignored Fields list (e.g., `updated_at`, `last_modified_by`).
3. For each UNINTENDED change, assess the severity: LOW (cosmetic), MEDIUM (data integrity risk), HIGH (security, compliance, or business logic violation).
4. If any UNINTENDED changes are found, generate a rollback suggestion that restores the original values for those fields.

# OUTPUT_SCHEMA
Return a single JSON object with this exact structure:
{
  "overall_verdict": "PASS" | "FAIL" | "WARNING",
  "intended_changes": [
    {
      "field": "string",
      "old_value": "any",
      "new_value": "any",
      "matches_intent": true | false
    }
  ],
  "unintended_changes": [
    {
      "field": "string",
      "old_value": "any",
      "new_value": "any",
      "severity": "LOW" | "MEDIUM" | "HIGH",
      "description": "string explaining the risk"
    }
  ],
  "noise_changes": [
    {
      "field": "string",
      "old_value": "any",
      "new_value": "any"
    }
  ],
  "rollback_actions": [
    {
      "field": "string",
      "restore_value": "any",
      "command": "string describing the rollback operation"
    }
  ]
}

# CONSTRAINTS
- Do not flag fields in the Ignored Fields list as UNINTENDED; classify them as NOISE.
- If an intended field's new value does not match the expected value, classify it as UNINTENDED with a description of the mismatch.
- If no unintended changes are found, set overall_verdict to "PASS" and return empty arrays for unintended_changes and rollback_actions.
- If only NOISE changes are found alongside intended changes, set overall_verdict to "PASS".
- If unintended changes are LOW severity only, set overall_verdict to "WARNING".
- If any MEDIUM or HIGH severity unintended changes exist, set overall_verdict to "FAIL".
- Do not invent fields or values not present in the input records.

# RISK_LEVEL
[HIGH] This validation gates downstream agent steps that may depend on record integrity. A false PASS can corrupt multi-step workflows. A false FAIL can stall legitimate operations. Human review is required for FAIL verdicts before rollback execution.

To adapt this prompt for your own agent pipeline, start by defining your [IGNORED_FIELDS_LIST] carefully. Every system has fields that change on every write—updated_at timestamps, version counters, or last_modified_by user IDs. If you omit these from the ignored list, the prompt will flag them as unintended changes on every run, producing noisy FAIL verdicts. Conversely, if you add business-logic fields to the ignored list to suppress warnings, you risk masking real data corruption. Maintain this list as a configuration parameter that evolves with your schema, not a one-time hardcode. For the [INTENDED_MODIFICATIONS_LIST], pass the exact field-value pairs your agent's update step was instructed to apply. If your agent uses a dynamic update payload, extract the intended changes from the tool call arguments or the step's declared postconditions. After pasting this prompt into your validation harness, always run it against a set of known test cases—including records with only noise changes, records with a single unintended change, and records where an intended field was set to the wrong value—to confirm the verdict logic behaves as expected before deploying to production.

The Record Update Field Comparison Prompt is designed to sit at a critical gating point in an agent pipeline: immediately after a tool call that mutates an existing database record. Its job is to compare the pre-mutation and post-mutation state of the record and confirm that only the intended fields changed. This is not a general-purpose diff tool; it is a targeted safety check for agents operating on mutable resources where an undetected field corruption can silently poison downstream reasoning. The harness must therefore treat this prompt as a mandatory validation step, not an optional diagnostic. If the prompt flags an unintended change, the pipeline should halt, roll back, or escalate—never proceed blindly.

To wire this prompt into an application, start by capturing a snapshot of the target record before the mutation tool executes. Store this as a structured JSON object in the agent's short-term memory or a dedicated pre_state variable. After the mutation tool returns a success response, retrieve the same record again to capture the post_state. Both states must be normalized to the same schema before they are passed to the prompt. Common normalization steps include stripping internal metadata fields (e.g., _id, _rev, _etag), converting timestamps to a consistent format, and removing computed or auto-generated fields that are expected to change on every write. If you skip normalization, the prompt will drown in noise from audit timestamps and revision tokens, producing false-positive unintended-change flags that erode trust in the validation layer.

The prompt's input variables are [PRE_STATE], [POST_STATE], and [INTENDED_CHANGES]. [INTENDED_CHANGES] should be a structured description of which fields the agent intended to modify and their expected new values. This is not the same as the raw tool arguments; it is a declarative statement of intent that the agent should produce before calling the mutation tool. For example: 'Update status to "active" and set last_contacted to 2025-03-15T10:00:00Z. No other fields should change.' The harness should validate that [INTENDED_CHANGES] is present and well-formed before invoking the prompt. If the agent cannot articulate its intent, the pipeline should refuse to execute the mutation.

Post-processing the prompt's output requires a structured parser that expects a JSON object with at minimum three keys: unintended_changes (an array of field-level diffs), rollback_recommended (a boolean), and rollback_actions (a list of suggested corrective steps). The harness should validate this schema strictly. If the model returns malformed JSON, retry once with a repair prompt that includes the raw output and the expected schema. If the second attempt also fails, escalate to a human operator with the raw output and both state snapshots. Do not silently proceed past a schema validation failure—this is the exact scenario where the safety check is most needed.

Retry logic for this prompt should be conservative. A single retry on schema validation failure is acceptable. Do not retry on semantic findings—if the prompt reports unintended changes, the harness must treat that as a definitive signal, not a probabilistic one to be re-rolled. The model may occasionally flag a benign field update (e.g., a last_modified timestamp that normalization missed) as unintended. To handle this, implement a post-processing allowlist of fields that are known to be safe to ignore. If all flagged unintended changes match the allowlist, the harness can suppress the alert and proceed. If any flagged field is outside the allowlist, halt execution and route to a human review queue with the full diff, the agent's intended changes, and the prompt's raw output.

Human review gates are essential when this prompt fires in production. The review interface should display a side-by-side diff of the pre-state and post-state records, highlight the fields the agent intended to change, and visually flag any unintended changes detected by the prompt. The human reviewer should have one-click actions to approve the change (overriding the prompt's warning), roll back the record to its pre-state, or manually correct the corrupted fields. Every review decision must be logged with the reviewer's identity, timestamp, and action taken. This audit trail is critical for debugging agent behavior and for compliance in regulated environments where automated data mutations require traceable oversight.

Model choice matters for this prompt. The task requires precise field-by-field comparison with low tolerance for hallucinated diffs. Use a model with strong structured output capabilities and low error rates on detail-oriented comparison tasks. Avoid models known to summarize or elide differences. Set the temperature to 0 or near-zero to minimize variance. If your pipeline uses a smaller, faster model for cost reasons, consider routing this specific validation step to a more capable model—the incremental cost is trivial compared to the cost of undetected data corruption propagating through downstream agent steps.