An agent has emitted a JSON migration plan for a production database. Before the agent proceeds to generate and apply scripts, the team wants to validate the plan programmatically. Which validation approach is MOST comprehensive for preventing dangerous migrations from proceeding?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A plan review that only checks spelling is not the same as one that catches 'DROP TABLE users without a backup.' Real plan validation combines schema correctness (are all required fields present and typed correctly?) with semantic rule checks (does this plan include operations that are banned without explicit authorization?). Option B layers both checks before any execution tool unlocks — that's comprehensive protection.
Full explanation below image
Full Explanation
Validating an agent's plan before execution requires two distinct layers: structural validation and semantic rule enforcement. Together, they catch both malformed plans and plans that are structurally valid but operationally dangerous.
Option B is correct. Structural validation (JSON Schema) ensures the plan is parseable, all required fields are present, and data types are correct — catching malformed plans before they even reach rule evaluation. The semantic rule engine then applies domain-specific safety checks: prohibiting DROP operations without a backup_confirmed flag, rejecting plans with estimated_rows_affected > 1,000,000 unless an explicit large_table_approved flag is set, and blocking irreversible operations on production targets without a rollback_procedure. Only after both layers pass are execution tools unlocked. This is automated, consistent, and auditable.
Option A (human reads JSON and posts a comment) introduces human latency, inconsistency, and fatigue. It also relies on the chat thread as an approval mechanism — which is informal, not tied to the agent's execution gate, and easily bypassed. Human review is valuable as a gate in high-risk scenarios, but it must be integrated into the approval workflow programmatically, not through a chat comment.
Option C (agent self-validates its own plan) is fundamentally insufficient. The same model that produced the plan will not reliably catch its own errors — this is analogous to proofreading your own writing. Self-validation provides no external check and introduces no structural barrier to execution.
Option D (linting generated scripts) operates too late. Linting happens after scripts are generated, which means the agent has already moved past the planning phase. Script linting is a valid quality gate but it is an execution-phase check, not a plan-phase check. The goal is to validate before any code generation begins.
The exam objective is: 'Validate agent plans.' The pattern is schema validation + semantic rule engine applied to the plan artifact before execution tools are unlocked.