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?

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.

The correct approach is the one that validates the JSON plan against a JSON Schema to enforce field types and required fields, then uses a rule engine to check for prohibited operations before any execution tool is unlocked. Structural validation through 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 greater than 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.

The manual senior-engineer review, where a senior engineer reads the JSON output and posts an approval comment in the agent's chat thread, 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.

The agent self-validation approach, where the agent re-reads its own plan output and confirms it looks correct before proceeding, is fundamentally insufficient. The same model that produced the plan will not reliably catch its own errors, which is analogous to proofreading your own writing. Self-validation provides no external check and introduces no structural barrier to execution.

The CI linter approach, where a CI job runs a linter against the generated migration scripts to catch syntax errors before deployment, 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 plus a semantic rule engine applied to the plan artifact before execution tools are unlocked.