WALKTHROUGH: one local Ollama attempt; synthetic Terraform evidence.
The model selects questions; Python owns the review decision.

R001: create -> delete
R002: no-op
R003: delete
R004: delete -> create

CAPTURED CLI: ai_review.py examples/plans/destructive.json --provider ollama
Output is saved in this recording folder under review/.
Waiting for the actual model response; no retries or substituted answers.
AI review: ollama; policy=review_required; exit=1
Observed review exit: 1

WALKTHROUGH: exit 1 means human review is required. It is not a provider error.
Observed CLI wall time: 60.203 seconds.
Reported chat latency: 60047 ms.

VALIDATED REPORT:

# AI-assisted Terraform review

Provider: ollama

Deterministic policy: **review_required**

Advisory only. This report is not approval to apply.

Local input SHA-256: 752e131164f2b2513b9fb380dbc2c06b82d597ad5510821d33b677d2cbfe9f4a


## R001 azurerm_virtual_network_peering.hub_to_team_b["team_b"]

Evidence: `/resource_changes/2/change`; mode: managed; actions: create -> delete; unknown values: not_reported.

Replacement includes removal of the old object. Review ordering, dependencies and recovery.

- How will cutover and temporary capacity be verified before the old object is removed?
- Which dependent services need verification before and after this change?
- What tested recovery procedure and retained data are available if this change fails?
- Which functional and monitoring checks will confirm the intended result?

## R002 module.hub.azurerm_virtual_network.this

Evidence: `/resource_changes/3/change`; mode: managed; actions: no-op; unknown values: not_reported.

No resource action is listed. This does not prove the wider deployment is safe.

- Which dependent services need verification before and after this change?
- Which functional and monitoring checks will confirm the intended result?

## R003 module.team_b["team_b"].azurerm_subnet.workload

Evidence: `/resource_changes/0/change`; mode: managed; actions: delete; unknown values: not_reported.

Removal is planned. Check dependencies, retained data and recovery before proceeding.

- Which dependent services need verification before and after this change?
- What tested recovery procedure and retained data are available if this change fails?
- Which functional and monitoring checks will confirm the intended result?

## R004 module.team_b["team_b"].azurerm_virtual_network.this

Evidence: `/resource_changes/1/change`; mode: managed; actions: delete -> create; unknown values: not_reported.

Replacement includes removal of the old object. Review ordering, dependencies and recovery.

- Which dependent services need verification before and after this change?
- What interruption window is acceptable when destruction precedes creation?
- What tested recovery procedure and retained data are available if this change fails?
- Which functional and monitoring checks will confirm the intended result?

Limits: no attribute analysis, dependency graph, cost estimate, live outage prediction, deployment execution or signature verification. Input hashes identify bytes but do not authenticate them.