Side Effect Prediction and Review Prompt Template

This prompt is designed for platform engineers and operators who manage AI agents with the authority to mutate production databases, cloud infrastructure, customer records, or external service configurations. The core job-to-be-done is generating a complete, structured prediction of every observable side effect before any execution step begins. This side-effect manifest serves as the input to a human approval gate or an automated policy engine, ensuring that no mutation occurs without explicit review. The ideal user is someone who already has a plan review process but finds that it lacks systematic enumeration of state changes, data mutations, external API calls with write intent, configuration updates, and notification triggers.

Use this prompt when the cost of an unanticipated mutation is high—for example, when a misplaced database write could corrupt customer data, or an incorrect infrastructure change could cause an outage. It is appropriate for workflows where the agent operates on mutable, shared resources and where the existing execution engine does not already produce a deterministic side-effect manifest. The prompt is particularly valuable in regulated environments where audit trails of predicted versus actual side effects are required. You should also use it when your team needs to scale human review by standardizing what reviewers look for, rather than relying on ad-hoc plan inspection.

Do not use this prompt for read-only analysis plans, plans that operate entirely in sandboxed or ephemeral environments, or plans where side effects are already fully described by a deterministic execution engine. If your agent is only performing search, summarization, or classification with no write operations, this prompt adds unnecessary latency and token cost. Similarly, if you are using a workflow engine that already outputs a complete list of intended mutations as part of its execution contract, running this prompt would be redundant. Avoid using it as a substitute for proper sandbox testing—this prompt predicts side effects, but it does not execute or validate them. Always pair the output with actual pre-execution testing where possible.

This prompt template is designed to be inserted into an agent planning pipeline immediately after a plan is generated but before any execution step begins. It forces the model to enumerate every state change, external service call, data mutation, and irreversible action the plan would produce. The output is a side-effect manifest that can be passed to a human approval queue, logged for audit, or compared against a policy engine. Use this when your agent operates on production databases, cloud infrastructure, customer-facing APIs, or any system where unintended mutations carry real cost.

textCopy
You are a side-effect auditor for an autonomous agent system. Your job is to predict every observable side effect of the following execution plan before any step runs. Do not execute the plan. Do not suggest alternatives. Only produce the side-effect manifest.

## PLAN TO AUDIT
[PLAN]

## AVAILABLE TOOLS AND CAPABILITIES
[TOOL_MANIFEST]

## TARGET ENVIRONMENT CONTEXT
[ENVIRONMENT_CONTEXT]

## CONSTRAINTS
- Classify each side effect by type: STATE_CHANGE, EXTERNAL_CALL, DATA_MUTATION, IRREVERSIBLE_ACTION, OBSERVABLE_OUTPUT, or NO_SIDE_EFFECT.
- For each side effect, specify: the step that causes it, the resource affected, the expected before/after state, whether it is reversible, and the blast radius if it fails.
- Flag any side effect that crosses a trust boundary (e.g., production vs. staging, internal vs. customer-facing, read-only vs. write).
- If a step's side effects depend on runtime data not available at plan time, mark it as CONDITIONAL and describe the branching possibilities.
- Rate each side effect's risk as LOW, MEDIUM, HIGH, or CRITICAL based on reversibility, blast radius, and trust boundary crossing.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "plan_id": "string",
  "audit_timestamp": "string (ISO 8601)",
  "total_steps_audited": integer,
  "side_effects": [
    {
      "step_id": "string",
      "step_description": "string",
      "effect_type": "STATE_CHANGE | EXTERNAL_CALL | DATA_MUTATION | IRREVERSIBLE_ACTION | OBSERVABLE_OUTPUT | NO_SIDE_EFFECT",
      "resource_affected": "string (fully qualified resource identifier)",
      "pre_state": "string (description of state before execution)",
      "post_state": "string (description of expected state after execution)",
      "is_reversible": boolean,
      "reversal_procedure": "string or null (how to undo, if reversible)",
      "blast_radius": "string (what else is affected if this fails)",
      "trust_boundary_crossed": boolean,
      "trust_boundary_detail": "string or null",
      "conditionality": "UNCONDITIONAL | CONDITIONAL",
      "condition_description": "string or null (branching scenarios if conditional)",
      "risk_level": "LOW | MEDIUM | HIGH | CRITICAL",
      "risk_rationale": "string"
    }
  ],
  "approval_recommendation": "PROCEED | PROCEED_WITH_CAUTION | REQUIRES_REVIEW | BLOCKED",
  "approval_rationale": "string (summary of why this recommendation was reached)",
  "flagged_steps": [
    {
      "step_id": "string",
      "concern": "string",
      "severity": "LOW | MEDIUM | HIGH | CRITICAL"
    }
  ]
}

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
Current operating risk level: [RISK_LEVEL]
If RISK_LEVEL is HIGH or CRITICAL, flag every irreversible action and every trust boundary crossing for mandatory human review.

Adapt this template by replacing the square-bracket placeholders with your actual plan representation, tool manifest, environment context, and few-shot examples. The [PLAN] placeholder should contain the full step-by-step plan as generated by your planning module, including step IDs, descriptions, and tool assignments. The [TOOL_MANIFEST] should list every tool available to the agent with its capabilities, permissions, and side-effect profiles if known. The [ENVIRONMENT_CONTEXT] should describe the target system state, including which resources are production, which are read-only, and any known constraints. The [FEW_SHOT_EXAMPLES] placeholder is critical for output consistency—provide at least two examples showing correct side-effect classification across different effect types. The [RISK_LEVEL] parameter should be set by your runtime based on the operating context: use LOW for development and staging environments, MEDIUM for internal tools, HIGH for customer-facing systems, and CRITICAL for production infrastructure or regulated data. Before deploying this prompt, validate that your plan representation includes stable step IDs that survive across planning and auditing stages, and ensure your approval gate can parse the JSON output schema without field name mismatches.

This prompt is not a conversational assistant; it is a pre-execution safety validator that must sit inside a deterministic application harness. The harness is responsible for feeding the prompt a complete plan object and a structured environment manifest, then parsing the predicted side-effect manifest into a machine-readable format for downstream gating logic. The prompt itself is stateless—every call must receive the full plan and context because side-effect analysis depends on the interaction between the plan steps and the target environment's current state.

Wire the prompt into a review gate that executes synchronously after plan generation and before any tool dispatch. The application layer must: (1) assemble the [PLAN] as a JSON array of steps with id, action, target_resource, and parameters; (2) build the [ENVIRONMENT_MANIFEST] describing mutable resources, their current state, and access scopes; (3) call the model with response_format set to a strict JSON schema matching the expected side-effect manifest; (4) validate the output against that schema, rejecting any response where predicted_side_effects is not an array or risk_level is not one of the allowed enum values; (5) if validation fails, retry once with the validation error appended to the prompt as a [PREVIOUS_ERROR] constraint. After two failures, escalate to a human reviewer and block execution. For high-risk environments, add a human approval queue step: if any side effect has severity: "critical" or irreversible: true, route the manifest to a review UI and pause the agent until approval is received.

Model choice matters here. Use a model with strong structured output support and low hallucination rates on enumeration tasks—frontier models with JSON mode enabled are preferred. Set temperature to 0 or near-zero to maximize consistency. Log every side-effect prediction alongside the plan version, environment manifest hash, and final execution outcome. This creates a feedback loop: compare predicted side effects against actual observed side effects from execution logs to build an eval dataset for tuning the prompt or fine-tuning a smaller classifier model. Do not use this prompt for real-time latency-sensitive paths where the review gate would violate a user-facing SLA; in those cases, pre-compute side-effect manifests for known plan templates and use the prompt only for novel or high-variance plans.