Terraform vs OpenTofu

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Terraform
   Terraform~partialprobed3/10

   Terraform has no llms.txt or docs.md agent-readable file (confirmed 404 by probes), so the specific artifact requested by the story is absent. However, HashiCorp does provide an official MCP server that gives AI models real-time access to Terraform provider documentation, modules, and policies, which is an agent-oriented documentation access mechanism, giving partial credit. Missing for 10: an actual llms.txt/docs.md file, and any evidence the MCP server is a drop-in substitute for llms.txt-style doc consumption.

   • [probe] “PROBE llms.txt: HTTP 404 at https://developer.hashicorp.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://developer.hashicorp.com/terraform/docs.md”
   • [claimed-docs] “The Terraform Model Context Protocol (MCP) server enhances AI models with real-time access to current Terraform provider documentation, modu…”
   • [claimed-docs] “AI enhancement: Enables more accurate and actionable Terraform configuration generation.”

   proof ↗⚑ flag

   OpenTofu—none0/10

   A direct probe of https://opentofu.org/llms.txt returned HTTP 404, and no other evidence pack items reference an llms.txt file or agent-oriented documentation format; the docs are standard human-facing pages only.

   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://opentofu.org/docs/.md”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round drawn
   Terraform✓fullprobed9/10

   Terraform CLI is fully scriptable/headless: non-interactive apply via -auto-approve, machine-readable JSON output (-json flag on show, plan, apply), plan files for two-step CI pipelines, and Terraform tests for CI validation — all well documented and widely used in CI/CD pipelines. missing for 10: independent hands-on report of a specific CI pipeline configuration (e.g., GitHub Actions) rather than just docs.

   • [claimed-docs] “-auto-approve - Skips interactive approval of the plan before applying”
   • [claimed-docs] “You can pass the `-auto-approve` option to instruct Terraform to apply the plan without asking for confirmation.”
   • [claimed-docs] “the -json flag outputs a stream of JSON UI messages”
   • [claimed-docs] “For long-running commands such as `plan`, `apply`, `refresh`, and `test`, the `-json` flag outputs a stream of JSON UI messages.”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [claimed-docs] “Terraform tests let authors validate that module configuration updates do not introduce breaking changes. Tests run against test-specific, s…”
   • [claimed-docs] “Terraform v1.7.0 introduced the ability to mock data returned by the providers during a `terraform test` execution.”
   • [probe] “official CLI documented at https://developer.hashicorp.com/terraform/cli”

   proof ↗⚑ flag

   OpenTofu✓fullprobed9/10

   Hands-on probes confirm OpenTofu supports non-interactive, scriptable CI workflows: `-input=false`, `-auto-approve`, `-detailed-exitcode` for change detection, machine-readable JSON plan output via `tofu show -json`, and a full plan→apply→destroy loop with correct exit codes, all installable without a login/keys via brew — exactly what CI/agent automation needs. Missing for 10: no explicit vendor CI/CD integration guide (e.g., GitHub Actions/GitLab CI docs) or third-party CI pipeline examples in the evidence pack.

   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”

   proof ↗⚑ flag

3. ai-native userUse an official CLI

   weight 2 · round to OpenTofu
   Terraform✓fullprobed8/10

   Terraform ships an official CLI with extensive documented commands (plan, apply, show, import, state, test) plus machine-readable JSON output modes (-json flags) that make it scriptable/consumable by AI agents, and HashiCorp also documents an official MCP server for AI integration. missing for 10: independent hands-on confirmation of AI-native agentic CLI usage patterns beyond docs, and no evidence of AI-specific CLI enhancements (e.g., natural-language CLI mode) beyond the JSON output and MCP server.

   • [probe] “official CLI documented at https://developer.hashicorp.com/terraform/cli”
   • [claimed-docs] “Add the `-json` command-line flag to generate machine-readable output.”
   • [claimed-docs] “For long-running commands such as `plan`, `apply`, `refresh`, and `test`, the `-json` flag outputs a stream of JSON UI messages.”
   • [claimed-docs] “the `-json` flag outputs a stream of JSON UI messages. The ouptut messages appear one per line so that you can process the messages”
   • [claimed-docs] “The Terraform Model Context Protocol (MCP) server enhances AI models with real-time access to current Terraform provider documentation, modu…”
   • [probe] “official MCP server documented at https://developer.hashicorp.com/terraform/mcp-server”

   proof ↗⚑ flag

   OpenTofu✓fullprobed9/10

   OpenTofu ships an official, documented CLI (opentofu.org/docs/cli/) and hands-on probes confirm a full headless workflow — init, plan with machine-readable JSON output, auto-approved apply, and destroy — all scriptable without interactive input, which is exactly what an AI-native/agentic caller needs. It is also a drop-in Terraform replacement, so existing agent tooling built for Terraform's CLI works unchanged. missing for 10: no first-party documentation specifically addressing AI-agent usage patterns or guardrails (e.g., rate limits, agent-specific auth flows) beyond generic CLI/JSON support.

   • [probe] “official CLI documented at https://opentofu.org/docs/cli/”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”

   proof ↗⚑ flag

4. ai-native userDrive the product through a documented public API

   weight 3 · round to Terraform
   Terraform~partialprobed6/10

   Terraform exposes machine-readable interfaces AI agents could drive: JSON output from plan/apply/show, a documented CLI, and an official MCP server built specifically to give AI models access to Terraform docs/modules/policies (terraform-docs-10/23/36/40, terraform-probe-4). However, probes confirm there is no discoverable OpenAPI/REST API spec or llms.txt (terraform-probe-1/2/3), so the 'documented public API' is really CLI+JSON+MCP rather than a conventional API surface. Missing for 10: a formal OpenAPI/REST API specification, an llms.txt or machine-readable docs index, and independent confirmation that AI agents successfully drive Terraform end-to-end via these interfaces.

   • [claimed-docs] “the -json flag outputs a stream of JSON UI messages”
   • [claimed-docs] “Add the `-json` command-line flag to generate machine-readable output.”
   • [claimed-docs] “For long-running commands such as `plan`, `apply`, `refresh`, and `test`, the `-json` flag outputs a stream of JSON UI messages.”
   • [claimed-docs] “the `-json` flag outputs a stream of JSON UI messages. The ouptut messages appear one per line so that you can process the messages”
   • [claimed-docs] “The Terraform Model Context Protocol (MCP) server enhances AI models with real-time access to current Terraform provider documentation, modu…”
   • [claimed-docs] “The Terraform Model Context Protocol (MCP) server enhances AI models with real-time access to current Terraform provider documentation, modu…”
   • [claimed-docs] “enhances AI models with real-time access to current Terraform provider documentation, modules, and policies from the Terraform registry”
   • [claimed-docs] “AI enhancement: Enables more accurate and actionable Terraform configuration generation.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developer.hashicorp.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://developer.hashicorp.com/terraform/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.hashicorp.com/openapi.json, https://developer.hashicorp.com/swagger.json, https://…”
   • [probe] “official MCP server documented at https://developer.hashicorp.com/terraform/mcp-server”
   • [probe] “official CLI documented at https://developer.hashicorp.com/terraform/cli”

   proof ↗⚑ flag

   OpenTofu~partialprobed5/10

   OpenTofu is drivable programmatically via its CLI (headless plan/apply/destroy loop, machine-readable JSON plan output) as confirmed by hands-on probes, which supports AI-native agentic automation, but there is no documented public HTTP/REST/OpenAPI API — probes for llms.txt, docs-md, and openapi/swagger endpoints all 404. missing for 10: a documented public API (REST/OpenAPI/SDK) beyond the CLI, official llms.txt or machine-readable docs endpoint, and any first-party API reference for programmatic/agentic access.

   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://opentofu.org/docs/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://opentofu.org/openapi.json, https://opentofu.org/swagger.json, https://opentofu.org/api/opena…”
   • [probe] “official CLI documented at https://opentofu.org/docs/cli/”

   proof ↗⚑ flag

5. ai-native userBuild against official SDKs

   weight 2 · round to Terraform
   Terraform~partialclaimed4/10

   Evidence shows Terraform exposes a plugin SDK for writing custom providers (terraform-docs-29) and machine-readable JSON output for programmatic consumption (terraform-docs-4/8/18/22/34), plus an official MCP server for AI models (terraform-docs-10/23/36/40), but there is no documented official SDK (e.g., CDK for Terraform or a language-native SDK) that AI-native builders could target directly. missing for 10: explicit official SDK documentation (e.g., CDKTF), examples of programmatic/AI-driven SDK usage, independent hands-on confirmation of SDK reliability.

   • [claimed-docs] “You can also [write your own](/terraform/plugin).”
   • [claimed-docs] “terraform show -json shows a JSON representation of the plan, configuration, and current state”
   • [claimed-docs] “the -json flag outputs a stream of JSON UI messages”
   • [claimed-docs] “The Terraform Model Context Protocol (MCP) server enhances AI models with real-time access to current Terraform provider documentation, modu…”
   • [claimed-docs] “The Terraform Model Context Protocol (MCP) server enhances AI models with real-time access to current Terraform provider documentation, modu…”
   • [claimed-docs] “AI enhancement: Enables more accurate and actionable Terraform configuration generation.”

   proof ↗⚑ flag

   OpenTofu—none0/10

   The evidence pack shows only CLI usage, JSON plan output, and website docs; there is no mention of any official SDK (Go, Python, REST, or agent-oriented) that AI-native developers could build against, and probes explicitly show llms.txt, docs-md, and OpenAPI endpoints returning 404. Missing for 10: any documented official SDK, API/OpenAPI spec, or programmatic library for AI agents to integrate with OpenTofu beyond the CLI.

   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://opentofu.org/docs/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://opentofu.org/openapi.json, https://opentofu.org/swagger.json, https://opentofu.org/api/opena…”
   • [probe] “official CLI documented at https://opentofu.org/docs/cli/”

   proof ↗⚑ flag

Agentic features

1. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Terraform
   Terraform~partialclaimed5/10

   Terraform's CLI supports scripted, non-interactive runs (-auto-approve, machine-readable -json output for plan/apply/show) that can be wired into external schedulers or CI/CD pipelines, and the MCP server exposes provider/module/policy context to AI agents for generating configs (terraform-docs-3, terraform-docs-17, terraform-docs-18, terraform-docs-22, terraform-docs-23/40). However, there is no evidence of a native scheduler, trigger, or always-on autonomous run loop within Terraform itself — automation depends on external orchestration (CI, HCP Terraform runs) not documented here. Missing for 10: native scheduling/trigger mechanism, evidence of unattended background execution loop, and independent confirmation of AI agents autonomously running plan/apply cycles.

   • [claimed-docs] “-auto-approve - Skips interactive approval of the plan before applying”
   • [claimed-docs] “You can pass the `-auto-approve` option to instruct Terraform to apply the plan without asking for confirmation.”
   • [claimed-docs] “Add the `-json` command-line flag to generate machine-readable output.”
   • [claimed-docs] “For long-running commands such as `plan`, `apply`, `refresh`, and `test`, the `-json` flag outputs a stream of JSON UI messages.”
   • [claimed-docs] “The Terraform Model Context Protocol (MCP) server enhances AI models with real-time access to current Terraform provider documentation, modu…”
   • [claimed-docs] “AI enhancement: Enables more accurate and actionable Terraform configuration generation.”
   • [claimed-docs] “Policies are rules for Terraform runs that let you validate that Terraform plans comply with security rules and best practices.”

   proof ↗⚑ flag

   OpenTofu~partialprobed4/10

   OpenTofu's CLI is fully non-interactive/keyless and scriptable (headless plan→apply→destroy verified in probes), which is a prerequisite for wiring it into cron jobs or CI/CD pipelines for autonomous runs, but there is no evidence of any built-in scheduler, trigger, webhook, or agent runtime that autonomously initiates or manages background runs on its own. missing for 10: native scheduling/trigger mechanism, evidence of autonomous (not just headless) background operation, first-party automation/orchestration features beyond CLI scriptability.

   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

2. ai-native userOperate the product with natural-language commands

   weight 2 · round to Terraform
   Terraform~partialprobed4/10

   Terraform's core interface remains HCL config files and explicit CLI commands (plan/apply/import), not natural language. The official MCP server gives AI models real-time access to provider docs, modules, and policies to help generate more accurate configurations, which is a step toward AI-native operation, but there is no evidence of a natural-language command interface for running Terraform actions directly. Missing for 10: a documented NL-to-command translation layer, evidence of AI agents actually driving terraform plan/apply via natural language, and independent corroboration of the MCP server enabling full operational control rather than just documentation lookup.

   • [claimed-docs] “The Terraform Model Context Protocol (MCP) server enhances AI models with real-time access to current Terraform provider documentation, modu…”
   • [claimed-docs] “The Terraform Model Context Protocol (MCP) server enhances AI models with real-time access to current Terraform provider documentation, modu…”
   • [claimed-docs] “AI enhancement: Enables more accurate and actionable Terraform configuration generation.”
   • [probe] “official MCP server documented at https://developer.hashicorp.com/terraform/mcp-server”

   proof ↗⚑ flag

   OpenTofu—none0/10

   OpenTofu's interface is HCL configuration plus a fixed CLI command set (plan, apply, test, import, etc.); nothing in the evidence pack shows any natural-language command interface, NL parsing, or AI-native control surface — llms.txt and other AI-discovery probes even returned 404s.

   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://opentofu.org/docs/.md”
   • [probe] “official CLI documented at https://opentofu.org/docs/cli/”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Terraform—none0/10

   The evidence pack shows standard static documentation pages and CLI references, but no interactive API reference or runnable code examples; probes explicitly confirm absence of machine-readable docs formats (llms.txt, docs.md, OpenAPI spec all 404).

   • [probe] “PROBE llms.txt: HTTP 404 at https://developer.hashicorp.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://developer.hashicorp.com/terraform/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.hashicorp.com/openapi.json, https://developer.hashicorp.com/swagger.json, https://…”

   proof ↗⚑ flag

   OpenTofu—none0/10

   OpenTofu's docs are static CLI command references (plan/apply/test/import) with no interactive API explorer or runnable-example sandbox; explicit probes confirm no OpenAPI/swagger spec and no llms.txt discoverability aid.

   • [probe] “PROBE openapi: all candidate paths 404 (https://opentofu.org/openapi.json, https://opentofu.org/swagger.json, https://opentofu.org/api/opena…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “The `tofu test` command lets you test your OpenTofu configuration by creating real infrastructure and checking that the required conditions …”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Terraform—none0/10

   Explicit probes for llms.txt, docs.md, and multiple OpenAPI/swagger endpoints all returned 404, and no evidence pack item references a downloadable OpenAPI or equivalent machine-readable API spec for Terraform.

   • [probe] “PROBE llms.txt: HTTP 404 at https://developer.hashicorp.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://developer.hashicorp.com/terraform/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.hashicorp.com/openapi.json, https://developer.hashicorp.com/swagger.json, https://…”

   proof ↗⚑ flag

   OpenTofu—none0/10

   Explicit probes confirm no OpenAPI/Swagger spec or llms.txt is available (404s at all candidate paths), and no evidence of any machine-readable API spec being offered.

   • [probe] “PROBE openapi: all candidate paths 404 (https://opentofu.org/openapi.json, https://opentofu.org/swagger.json, https://opentofu.org/api/opena…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://opentofu.org/docs/.md”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Terraform
   Terraform~partialclaimed6/10

   Terraform's built-in `terraform test` framework explicitly runs against test-specific, short-lived resources to avoid touching real infrastructure/state, and v1.7.0 added provider-response mocking so tests can run without any real cloud calls at all — a genuine sandbox mechanism. However, this is a general IaC testing feature, not something built or documented specifically for 'AI-native' agentic use, and there's no independent/hands-on evidence validating it in an AI-agent context. Missing for 10: explicit AI-agent-oriented sandbox tooling or workflow guidance, and independent corroboration that the test/mock framework reliably isolates AI-driven runs from production.

   • [claimed-docs] “Terraform tests let authors validate that module configuration updates do not introduce breaking changes. Tests run against test-specific, s…”
   • [claimed-docs] “Terraform v1.7.0 introduced the ability to mock data returned by the providers during a `terraform test` execution.”
   • [claimed-docs] “Terraform tests let authors validate that module configuration updates do not introduce breaking changes. Tests run against test-specific, s…”
   • [claimed-docs] “Terraform tests let authors validate that module configuration updates do not introduce breaking changes.”

   proof ↗⚑ flag

   OpenTofu~partialprobed5/10

   OpenTofu's `tofu test` command explicitly creates real infrastructure to test configuration and then destroys it, and workspaces/variables allow separate dev/staging/prod environments (multi-environment support mentioned in docs), which supports sandbox-style testing without touching production if configured with separate state/backends. However, there is no dedicated built-in sandboxing feature, no first-party guidance on isolating a sandbox from production data specifically, and no mocking/dry-run-only testing mode beyond plan preview. missing for 10: dedicated sandbox/mock-infrastructure feature, explicit doc guidance on isolating prod vs sandbox state, independent verification of test-command safety in practice.

   • [claimed-docs] “The `tofu test` command lets you test your OpenTofu configuration by creating real infrastructure and checking that the required conditions …”
   • [claimed-docs] “The `tofu test` command lets you test your OpenTofu configuration by creating real infrastructure and checking that the required conditions …”
   • [claimed-docs] “Dynamically generate provider configurations with for_each, eliminating repetitive code and improving maintainability. Perfect for multi-reg…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Terraform—none0/10

   While Terraform configurations support versioning (terraform-docs-1, terraform-docs-14) and providers/modules use semantic versioning via the registry (terraform-docs-11, terraform-docs-41), the evidence pack shows no documented API versioning scheme or deprecation policy for Terraform's APIs (e.g., Terraform Cloud API, provider protocol) — probes for openapi specs and machine-readable docs all 404 (terraform-probe-1, terraform-probe-2, terraform-probe-3). This axis applies to an infrastructure automation tool with APIs, but no evidence demonstrates a documented deprecation policy.

   • [probe] “PROBE llms.txt: HTTP 404 at https://developer.hashicorp.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://developer.hashicorp.com/terraform/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.hashicorp.com/openapi.json, https://developer.hashicorp.com/swagger.json, https://…”
   • [claimed-docs] “Anyone can publish and consume providers, modules, and policies on the public Terraform Registry.”
   • [claimed-docs] “Anyone can publish and consume providers, modules, and policies on the public Terraform Registry”

   proof ↗⚑ flag

   OpenTofu—none0/10

   The evidence pack shows OpenTofu has versioned CLI output formats (e.g., plan JSON format_version) but contains no documentation of a formal API/CLI deprecation policy or version-support guarantees; the axis is applicable to an IaC tool with a CLI/JSON interface, but no evidence supports a documented deprecation policy. Missing for 10: explicit deprecation policy docs, versioning/SLA guarantees, changelog of breaking changes.

   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “official CLI documented at https://opentofu.org/docs/cli/”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round drawn
   Terraform~partialprobed6/10

   Terraform's graph-based execution parallelizes non-dependent resource changes, and -auto-approve plus -json machine-readable output enable scripted, bulk plan/apply workflows across many resources, with an official MCP server for AI agent integration. However, evidence doesn't show a native 'bulk operation' primitive (e.g., bulk import/move across many items) beyond per-resource state/import commands. missing for 10: documented bulk import/bulk state-move across many resources in one command, independent hands-on evidence of AI agents driving large-scale bulk operations, and any explicit bulk-editing API beyond graph parallelization.

   • [github] “Terraform builds a graph of all your resources, and parallelizes the creation and modification of any non-dependent resources.”
   • [claimed-docs] “You can pass the `-auto-approve` option to instruct Terraform to apply the plan without asking for confirmation.”
   • [claimed-docs] “For long-running commands such as `plan`, `apply`, `refresh`, and `test`, the `-json` flag outputs a stream of JSON UI messages.”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [claimed-docs] “The Terraform Model Context Protocol (MCP) server enhances AI models with real-time access to current Terraform provider documentation, modu…”
   • [probe] “official MCP server documented at https://developer.hashicorp.com/terraform/mcp-server”

   proof ↗⚑ flag

   OpenTofu~partialclaimed6/10

   OpenTofu supports bulk-style operations via resource graph parallelization, for_each-driven dynamic provider/module generation, -exclude flag for scoping bulk plan/apply, and programmatic module version updates across many modules, which together enable acting on many items at once. However this is infrastructure-as-code bulk management, not an AI-native batch/agent API, and there's no evidence of a dedicated bulk API, batch job orchestration, or AI-specific tooling for mass operations. missing for 10: dedicated bulk/batch API or agent-facing interface for large-scale multi-item operations, independent hands-on evidence of bulk operations at scale, AI-native tooling specifically for orchestrating many items programmatically.

   • [github] “OpenTofu builds a graph of all your resources, and parallelizes the creation and modification of any non-dependent resources.”
   • [claimed-docs] “Selectively exclude resources from operations with the -exclude flag. This provides more control during testing and rollouts, allowing you t…”
   • [claimed-docs] “Dynamically generate provider configurations with for_each, eliminating repetitive code and improving maintainability.”
   • [claimed-docs] “Update all your modules programmatically with a single variable change. Never miss updating a module version by accident - keep your infrast…”
   • [claimed-docs] “Dynamically generate provider configurations with for_each, eliminating repetitive code and improving maintainability. Perfect for multi-reg…”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round drawn
   Terraform—none0/10

   The evidence shows Terraform's policy enforcement (Sentinel/OPA) validates plans against rules and its plan/apply workflow can be scripted, but there is no evidence of a built-in mechanism to define rules that automatically trigger actions in response to arbitrary events (e.g., event-driven automation, webhooks-to-action rules). Terraform relies on external CI/CD or HCP Terraform triggers, which aren't documented here.

   • [claimed-docs] “Policies are rules for Terraform runs that let you validate that Terraform plans comply with security rules and best practices.”
   • [claimed-docs] “View and override policy enforcement results in the workspace UI.”

   proof ↗⚑ flag

   OpenTofu—none0/10

   OpenTofu's evidence pack covers CLI plan/apply/test/import workflows but shows no rule-based or event-triggered automation engine (e.g., webhooks, event listeners, policy-triggered actions) built into the tool itself.

   ⚑ flag

3. ai-native userVersion, review, and roll back my automations

   weight 1 · round to Terraform
   Terraform~partialcommunity6/10

   Terraform configs are text files that can be versioned in git (terraform-docs-1/14/37), and `terraform plan`/`show -json` give strong review capabilities before apply (terraform-docs-2/15/26/39). However, there is no first-class 'rollback' command — reverting infrastructure requires reapplying an older config version or manual state manipulation via `terraform state` (terraform-docs-6/20), and HCP remote state storage is only recommended, not a rollback mechanism. Missing for 10: a documented native rollback/undo feature, and hands-on evidence of rollback workflows succeeding in practice.

   • [claimed-docs] “define both cloud and on-prem resources in human-readable configuration files that you can version, reuse, and share”
   • [claimed-docs] “creates an execution plan, which lets you preview the changes that Terraform plans to make to your infrastructure”
   • [claimed-docs] “Terraform provides the terraform state command to perform basic modifications of the state using the CLI.”
   • [claimed-docs] “Terraform uses your workspace's state to map real world resources to your configuration, keep track of metadata, and to improve performance …”
   • [claimed-docs] “The `terraform show` command provides human-readable output from a state or plan file.”
   • [claimed-docs] “We recommend storing state in HCP Terraform or a remote backend to securely store state and collaborate with team members.”
   • [community] “Terraform has a feature that is critical for safely iterating infrastructure: execution plans. Execution plans show you what changes Terrafo…”

   proof ↗⚑ flag

   OpenTofu~partialprobed5/10

   OpenTofu's state is plain text-based (HCL) which enables version control via git, and plan files (tofu plan -out) provide a preview/review mechanism, with tofu destroy/apply providing rollback-like operations, but there's no native built-in versioning, review workflow, or rollback/history feature beyond what git or external tools (e.g. Terraform Cloud-like state history) provide. missing for 10: no first-party state history/rollback mechanism, no built-in review/approval workflow beyond plan output, no independent evidence of an audit trail or diff-based rollback UI.

   • [claimed-docs] “Version control your infrastructure with OpenTofu. Track changes, collaborate with your team, and deploy DNS configurations with a single co…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

Import

1. platform-engineerImport existing cloud resources under management and generate matching configuration code

   weight 3 · round to OpenTofu
   Terraform!disputedcontradicted4/10

   Docs confirm `terraform import` can bring existing resources into state (terraform-docs-5/19/32), but the evidence pack has no mention of the newer -generate-config-out feature that produces matching HCL, and a first-hand community report explicitly says there's no good built-in way to import resources created outside Terraform, having to resort to a third-party tool of uncertain maintenance status (terraform-comm-10). This directly contradicts the 'generate matching configuration code' part of the story. Missing for 10: first-party documentation of automatic config-code generation during import, and corroboration that it works reliably in practice.

   • [claimed-docs] “You can import an existing resource to state from the Terraform CLI.”
   • [claimed-docs] “This topic provides an overview of the Terraform commands that let you import existing infrastructure resources so that you can manage them …”
   • [claimed-docs] “import existing infrastructure resources so that you can manage them with Terraform”
   • [community] “I haven't found a good way to handle resources that were created outside TF... They don't exist in TF state or config so TF simply ignores t…”

   proof ↗⚑ flag

   OpenTofu~partialcommunity6/10

   OpenTofu documents `tofu import` for importing existing resources into state, and community evidence confirms `for_each` support for import blocks (bulk import). However, evidence does not show automatic configuration-code generation from imported resources (e.g., a `-generate-config-out` style feature) — missing for 10: documentation/proof of automatic config generation during import, hands-on demonstration of the full import-to-config workflow, and independent verification of accuracy for generated code.

   • [claimed-docs] “The `tofu import` command imports existing resources into OpenTofu.”
   • [community] “"for_each" implementation for "import" blocks... Well, I'm officially on board with this project. We've been told this is impossible for yea…”

   proof ↗⚑ flag

Licensing

1. devops-leadRely on an open license and open governance so the tool cannot be relicensed out from under my company

   weight 3 · round to OpenTofu
   Terraform!disputedcontradicted3/10

   Terraform is marketed as open (public registry, GitHub repo) but the evidence shows concrete counter-signals to the 'open governance that can't be relicensed' promise: HashiCorp requires a CLA that community members explicitly object to, and users report HashiCorp 'yanked the okta/mfa feature from OSS' calling it 'pretty hostile' — both indicating the vendor retains unilateral control over licensing/features rather than a neutral, foundation-governed open project. missing for 10: any first-party statement on license terms (e.g. MPL/BSL) or a governance body/foundation guaranteeing the license can't change, and independent confirmation that community contributions are protected from relicensing.

   • [community] “Love the tool, hate the fact that they still work with a CLA. If anyone at HashiCorp is reading this, could you guys consider changing to a …”
   • [community] “Particularly when they yanked the okta/mfa feature from OSS, that was pretty hostile.”
   • [community] “My attempts to submit Pull Requests for much wanted features (fully working documentation with new integration tests all passing) often took…”
   • [claimed-docs] “Anyone can publish and consume providers, modules, and policies on the public Terraform Registry”

   proof ↗⚑ flag

   OpenTofu✓fullcommunity7/10

   OpenTofu explicitly ties its open-source guarantee to being hosted under the Linux Foundation, a neutral governance body designed to prevent unilateral relicensing — directly addressing the devops-lead's concern. Community commentary raises cultural/governance grumbles but no concrete evidence of relicensing risk or license violation, so this doesn't rise to a dispute. missing for 10: explicit license text/name (e.g., MPL 2.0) in evidence, details on governance structure (TSC, contribution/veto rules), and independent third-party corroboration of the Linux Foundation guarantee.

   • [claimed-docs] “Now that we are part of the Linux Foundation, we can guarantee that OpenTofu will remain: Truly open source”
   • [community] “It seems the license info is not readily available on the website. I can easily find it in the GitHub repo but not on the website. I think i…”
   • [community] “So far it appears to be the same old thing with a different owner. Maintainers act like they own the thing and everyone else (read: the user…”

   proof ↗⚑ flag

Stability

1. developerRely on documented compatibility promises and upgrade guides between releases

   weight 2 · round to OpenTofu
   Terraform—none0/10

   The evidence pack contains no documentation about version compatibility guarantees, semantic versioning policy, or upgrade guides between Terraform releases; it only covers CLI commands, state management, testing, and the MCP server. This axis clearly applies to a widely-used infra-as-code tool, but no supporting citations exist here.

   ⚑ flag

   OpenTofu~partialcommunity5/10

   OpenTofu publicly commits to backwards compatibility and positions itself as a drop-in replacement for Terraform, preserving existing configs/workflows, which implies a compatibility promise, but the evidence pack contains no explicit version-to-version upgrade guide documentation for OpenTofu releases themselves, and one community comment notes OpenTofu is 'already diverging from upstream,' raising uncertainty about long-term compatibility guarantees. missing for 10: dedicated upgrade-guide docs between OpenTofu minor/major releases, changelog/breaking-change policy evidence, independent confirmation of smooth upgrades across OpenTofu versions.

   • [claimed-docs] “Backwards-compatible - so that the existing code can drive value for years to come”
   • [claimed-docs] “It serves as a **drop-in replacement for Terraform**, preserving your existing workflows and configurations.”
   • [claimed-docs] “It serves as a drop-in replacement for Terraform, preserving your existing workflows and configurations.”
   • [community] “OpenTofu is already diverging from upstream but is relying on upstream providers so I'm not sure how to feel about it.”
   • [community] “Fortunately using OpenTofu is just s/terraform/opentofu/g at this point.”

   proof ↗⚑ flag

1. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Terraform~partialcommunity6/10

   Terraform's core artifacts are open by design: configurations are plain human-readable HCL files that users own, version, and share (terraform-docs-1/14/37), and state/plan data can be exported to machine-readable JSON via `terraform show -json` or manipulated via `terraform state` commands (terraform-docs-4/6/18/26/39), enabling a user to walk away with all their data in open formats. However there's no explicit 'export everything and migrate away' workflow or tooling documented, and community evidence notes friction around state portability (e.g., resources outside TF state being ignored, terraform-comm-10) and remote/Cloud-hosted state recommendations (terraform-docs-33) that could complicate a clean exit if using HCP Terraform. Missing for 10: an explicit data-export/migration guide, independent confirmation of a smooth 'leave the platform' path, and clarity on exporting HCP Terraform-hosted state without vendor dependency.

   • [claimed-docs] “define both cloud and on-prem resources in human-readable configuration files that you can version, reuse, and share”
   • [claimed-docs] “HashiCorp Terraform is an infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration …”
   • [claimed-docs] “terraform show -json shows a JSON representation of the plan, configuration, and current state”
   • [claimed-docs] “Terraform provides the terraform state command to perform basic modifications of the state using the CLI.”
   • [claimed-docs] “Add the `-json` command-line flag to generate machine-readable output.”
   • [claimed-docs] “The `terraform show` command provides human-readable output from a state or plan file.”
   • [claimed-docs] “We recommend storing state in HCP Terraform or a remote backend to securely store state and collaborate with team members.”
   • [community] “I haven't found a good way to handle resources that were created outside TF... They don't exist in TF state or config so TF simply ignores t…”

   proof ↗⚑ flag

   OpenTofu~partialprobed6/10

   OpenTofu's state and plan files are plain JSON/HCL (confirmed by the probed `tofu show -json` machine-readable output) and the project is governed as 'truly open source' under the Linux Foundation, meaning there is no proprietary lock-in and configs/state can be freely moved or forked. However, there is no explicit documentation of a dedicated 'export and leave' workflow, no discussion of migrating state to other tools, and no llms.txt/data-export interface (llms.txt 404, no OpenAPI) that would make this openness explicit for AI-native tooling. missing for 10: explicit data-export/portability docs, llms.txt or machine-readable manifest, third-party confirmation of migrating state out of OpenTofu.

   • [claimed-docs] “Now that we are part of the Linux Foundation, we can guarantee that OpenTofu will remain: Truly open source”
   • [claimed-docs] “Backwards-compatible - so that the existing code can drive value for years to come”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [community] “Fortunately using OpenTofu is just s/terraform/opentofu/g at this point.”

   proof ↗⚑ flag

2. ai-native userRead the product's source under an open license

   weight 2 · round to OpenTofu
   Terraform~partialcommunity4/10

   Terraform's source is publicly hosted on GitHub (terraform-gh-1), which lets an AI-native user read the code, and community discussion references a CLA-based open-source contribution model (terraform-comm-4). However, the evidence never states or links an explicit open-source license (e.g. MPL/BUSL identifier) for the repo, and community commentary notes HashiCorp "yanked" a feature from OSS (terraform-comm-13), suggesting the openness of the codebase is not unconditional. Missing for 10: explicit license documentation/SPDX reference, confirmation the full CLI source (vs. only some components) remains under an OSI-approved license, and resolution of the OSS-feature-removal concern.

   • [github] “Terraform builds a graph of all your resources, and parallelizes the creation and modification of any non-dependent resources.”
   • [community] “Love the tool, hate the fact that they still work with a CLA. If anyone at HashiCorp is reading this, could you guys consider changing to a …”
   • [community] “Particularly when they yanked the okta/mfa feature from OSS, that was pretty hostile.”

   proof ↗⚑ flag

   OpenTofu✓fullcommunity8/10

   OpenTofu's source is publicly hosted on GitHub (opentofu-gh-1) and the manifesto explicitly commits to remaining 'Truly open source' now under the Linux Foundation (opentofu-docs-26); community discussion confirms the license is readily found in the GitHub repo even if not prominent on the marketing site (opentofu-comm-3). Missing for 10: explicit citation of the license text/name (e.g., MPL 2.0) and independent legal/audit confirmation beyond community mention.

   • [github] “OpenTofu builds a graph of all your resources, and parallelizes the creation and modification of any non-dependent resources.”
   • [claimed-docs] “Now that we are part of the Linux Foundation, we can guarantee that OpenTofu will remain: Truly open source”
   • [community] “It seems the license info is not readily available on the website. I can easily find it in the GitHub repo but not on the website. I think i…”

   proof ↗⚑ flag

3. ai-native userSelf-host the core product

   weight 3 · round drawn
   Terraform✓fullcommunity8/10

   Terraform CLI itself is open-source, self-hostable software that runs locally without requiring HashiCorp's cloud, and evidence confirms open registry, self-authored providers, and CLI-only workflows (state, plan, apply) that don't require any hosted backend; community comments corroborate long-term self-hosted/open-source usage. missing for 10: no explicit evidence pack statement enumerating self-hosting deployment instructions or license details, and no independent audit confirming full feature parity without HCP/Cloud services.

   • [claimed-docs] “Automate Infrastructure on Any Cloud”
   • [claimed-docs] “HashiCorp Terraform is an infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration …”
   • [claimed-docs] “You can also [write your own](/terraform/plugin).”
   • [claimed-docs] “Anyone can publish and consume providers, modules, and policies on the public Terraform Registry”
   • [community] “I've been using Terraform for years, and I'm really glad to see it reach 1.0... thanks to you and your colleagues for consistently making th…”
   • [github] “Terraform builds a graph of all your resources, and parallelizes the creation and modification of any non-dependent resources.”

   proof ↗⚑ flag

   OpenTofu✓fullprobed8/10

   OpenTofu is fully open-source (Linux Foundation governed), can be installed and run entirely on one's own infrastructure via multiple install methods, and probes confirm a fully local, keyless CLI workflow (init/plan/apply/destroy) with no SaaS dependency — this is inherently self-hostable since it's just a binary operating on local/backend state. missing for 10: no explicit vendor documentation section titled 'self-hosting' or dedicated guide addressing enterprise/air-gapped self-hosted deployment scenarios, and no independent hands-on report specifically validating self-hosted production use at scale.

   • [claimed-docs] “You can install OpenTofu via a wide range of methods. Please select your operating system and installation method”
   • [claimed-docs] “Now that we are part of the Linux Foundation, we can guarantee that OpenTofu will remain: Truly open source”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”
   • [claimed-docs] “Backwards-compatible - so that the existing code can drive value for years to come”

   proof ↗⚑ flag

Agent plan parsing

1. ai-native userGet machine-readable plan output (JSON) that an agent can parse to reason about a proposed change

   weight 3 · round drawn
   Terraform✓fullclaimed9/10

   Terraform provides `terraform show -json` to output plan/state/config as JSON, and `-json` on plan/apply/refresh/test streams machine-readable JSON UI messages line-by-line for programmatic processing — both well-documented first-party capabilities directly matching the story. missing for 10: no independent/hands-on third-party corroboration of an agent actually parsing this JSON in practice.

   • [claimed-docs] “terraform show -json shows a JSON representation of the plan, configuration, and current state”
   • [claimed-docs] “Add the `-json` command-line flag to generate machine-readable output.”
   • [claimed-docs] “the -json flag outputs a stream of JSON UI messages”
   • [claimed-docs] “For long-running commands such as `plan`, `apply`, `refresh`, and `test`, the `-json` flag outputs a stream of JSON UI messages.”
   • [claimed-docs] “the `-json` flag outputs a stream of JSON UI messages. The ouptut messages appear one per line so that you can process the messages”
   • [claimed-docs] “the `terraform show` command provides human-readable output from a state or plan file... Add the `-json` command-line flag to generate machi…”

   proof ↗⚑ flag

   OpenTofu✓fullprobed9/10

   Hands-on probe confirms `tofu show -json plan.out` emits machine-readable plan JSON (format_version 1.2) with planned_values, parseable by agent tooling, alongside documented plan/apply CLI workflow supporting `-out=FILE` for later JSON conversion. missing for 10: no independent third-party corroboration beyond the single probe run.

   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”

   proof ↗⚑ flag

Ai infra ops

1. ai-native userHave an agent author an infrastructure change, run a plan headlessly, and present the diff for my approval

   weight 3 · round to OpenTofu
   Terraform~partialclaimed6/10

   Terraform's CLI supports the core mechanics: headless plan generation with -out, machine-readable JSON output via show -json and -json streaming, and apply requiring approval unless -auto-approve is passed, plus an official MCP server for AI integration with provider docs/modules/policies. However, there is no first-party documented workflow or tooling that specifically wires an agent to author config, run plan headlessly, and present a diff for human approval as an integrated feature — this is assembled by the user from separate primitives rather than a turnkey agent-approval pipeline. missing for 10: an end-to-end documented agent-authoring-to-approval workflow, evidence of the MCP server itself invoking plan/apply or diff presentation, and independent/hands-on confirmation of this exact human-in-the-loop pattern.

   • [claimed-docs] “The `terraform plan` command creates an execution plan, which lets you preview the changes that Terraform plans to make to your infrastructu…”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [claimed-docs] “Terraform automatically creates a new execution plan as if you had run terraform plan, prompts you to approve that plan, and performs the in…”
   • [claimed-docs] “the `terraform show` command provides human-readable output from a state or plan file... Add the `-json` command-line flag to generate machi…”
   • [claimed-docs] “For long-running commands such as `plan`, `apply`, `refresh`, and `test`, the `-json` flag outputs a stream of JSON UI messages.”
   • [claimed-docs] “-auto-approve` - Skips interactive approval of the plan before applying”
   • [claimed-docs] “The Terraform Model Context Protocol (MCP) server enhances AI models with real-time access to current Terraform provider documentation, modu…”
   • [claimed-docs] “AI enhancement: Enables more accurate and actionable Terraform configuration generation.”

   proof ↗⚑ flag

   OpenTofu✓fullprobed8/10

   Hands-on probes confirm a full headless plan→apply loop: `tofu plan -detailed-exitcode -out=plan.out` runs non-interactively and signals changes, `tofu show -json` emits machine-readable diff output parseable by agent tooling, and `tofu apply plan.out` executes the saved plan for approval-gated apply. This directly matches the story of an agent authoring changes, planning headlessly, and presenting a diff for approval. missing for 10: no first-party agent/CI orchestration example or official docs showing an approval-gate workflow built around the JSON plan output, and no independent (non-vendor) corroboration beyond the probe run.

   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”

   proof ↗⚑ flag

Automation api

1. developerDrive deployments programmatically from my own application code rather than only through the CLI

   weight 2 · round drawn
   Terraform—none0/10

   Evidence only shows CLI-based workflows (plan/apply/show -json, machine-readable UI output) that can be scripted or wrapped, but nothing indicates an official SDK, REST/HTTP API, or library for driving terraform plan/apply from application code without shelling out to the CLI. No mention of Terraform Cloud API, CDK for Terraform, or any programmatic library in the pack.

   • [claimed-docs] “The `terraform plan` command creates an execution plan, which lets you preview the changes that Terraform plans to make to your infrastructu…”
   • [claimed-docs] “The `terraform apply` command executes the operations proposed in a Terraform plan.”
   • [claimed-docs] “Add the `-json` command-line flag to generate machine-readable output.”
   • [claimed-docs] “For long-running commands such as `plan`, `apply`, `refresh`, and `test`, the `-json` flag outputs a stream of JSON UI messages.”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.hashicorp.com/openapi.json, https://developer.hashicorp.com/swagger.json, https://…”

   proof ↗⚑ flag

   OpenTofu—none0/10

   All evidence describes CLI commands (`tofu plan`, `apply`, `show -json`) and JSON output that can be parsed by external scripts, but there is no official SDK, Go library, or API for embedding OpenTofu operations directly in application code, and probes explicitly show no OpenAPI/API endpoints exist. This means programmatic control still requires shelling out to the CLI rather than a first-class application-integration path.

   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://opentofu.org/openapi.json, https://opentofu.org/swagger.json, https://opentofu.org/api/opena…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”

   proof ↗⚑ flag

Plan workflow

1. developerTear down an entire environment cleanly with a destroy operation

   weight 2 · round to OpenTofu
   Terraform—none0/10

   The evidence pack documents plan, apply, state, import, and test workflows in detail but never mentions a `terraform destroy` command or any teardown/cleanup operation. Without direct evidence of a destroy capability, this story cannot be credited even though it is a core plan-apply workflow axis for an IaC tool.

   ⚑ flag

   OpenTofu✓fullprobed9/10

   OpenTofu docs explicitly describe destroy-mode planning that removes all remote objects leaving an empty state, and a hands-on probe confirms a full plan→apply→destroy loop exiting cleanly (exit 0). This directly matches the story of tearing down an environment cleanly. Missing for 10: independent (non-probe) third-party confirmation of destroy behavior at scale or with complex multi-resource environments.

   • [claimed-docs] “Destroy mode: creates a plan whose goal is to destroy all remote objects that currently exist, leaving an empty OpenTofu state.”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

2. devops-leadRun plan and apply non-interactively in CI using saved plan artifacts and approval flags

   weight 3 · round drawn
   Terraform✓fullclaimed9/10

   Terraform's docs directly support the CI workflow: `terraform plan -out=FILE` saves a plan artifact, `terraform apply FILE` executes that exact saved plan, and `-auto-approve` skips interactive approval for non-interactive automation. Machine-readable JSON output (`-json` on show/plan/apply) further supports CI pipelines that need to parse results. missing for 10: no independent/hands-on CI pipeline example or third-party corroboration of this exact workflow.

   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [claimed-docs] “-auto-approve - Skips interactive approval of the plan before applying”
   • [claimed-docs] “-auto-approve` - Skips interactive approval of the plan before applying”
   • [claimed-docs] “-auto-approve - Skips interactive approval of the plan before applying.”
   • [claimed-docs] “The `terraform apply` command executes the operations proposed in a Terraform plan.”
   • [claimed-docs] “Add the `-json` command-line flag to generate machine-readable output.”
   • [claimed-docs] “the `-json` flag outputs a stream of JSON UI messages. The ouptut messages appear one per line so that you can process the messages”

   proof ↗⚑ flag

   OpenTofu✓fullprobed9/10

   Docs describe saving plans with `-out=FILE` and applying them via `tofu apply plan.out`, and hands-on probes confirm a full non-interactive plan→apply→destroy loop using `-input=false -auto-approve -detailed-exitcode`, matching the CI approval-flag workflow described in the story. missing for 10: explicit CI/CD pipeline examples (e.g., GitHub Actions/GitLab CI snippets) showing artifact upload/download between plan and apply stages.

   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

3. platform-engineerPreview exactly what will change — creates, updates, and destroys — before applying

   weight 3 · round to Terraform
   Terraform✓fullcommunity10/10

   terraform plan generates a detailed execution plan previewing creates/updates/destroys before any changes are made, with human-readable and JSON output options, and apply prompts for confirmation unless auto-approved; this core workflow is corroborated by both official docs and independent community testimony praising execution plans as a key safety feature.

   • [claimed-docs] “creates an execution plan, which lets you preview the changes that Terraform plans to make to your infrastructure”
   • [claimed-docs] “The `terraform plan` command creates an execution plan, which lets you preview the changes that Terraform plans to make to your infrastructu…”
   • [claimed-docs] “The `terraform apply` command executes the operations proposed in a Terraform plan.”
   • [claimed-docs] “Terraform automatically creates a new execution plan as if you had run terraform plan, prompts you to approve that plan, and performs the in…”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [claimed-docs] “the `terraform show` command provides human-readable output from a state or plan file... Add the `-json` command-line flag to generate machi…”
   • [community] “Terraform has a feature that is critical for safely iterating infrastructure: execution plans. Execution plans show you what changes Terrafo…”

   proof ↗⚑ flag

   OpenTofu✓fullprobed9/10

   OpenTofu's tofu plan command is explicitly documented to preview creates, updates, and destroys before applying, with dedicated destroy and refresh-only modes, and this was independently verified via a hands-on probe showing a real plan proposing a create, saved to a file, and later applied and destroyed successfully. Machine-readable plan JSON output further supports precise change previewing. missing for 10: independent third-party review of plan accuracy on complex multi-resource updates beyond the single-resource probe

   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “Destroy mode: creates a plan whose goal is to destroy all remote objects that currently exist, leaving an empty OpenTofu state.”
   • [claimed-docs] “Refresh-only mode: creates a plan whose goal is only to update the OpenTofu state and any root module output values to match changes made to…”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

4. platform-engineerTarget or exclude specific resources in a plan or apply

   weight 1 · round to OpenTofu
   Terraform—none0/10

   The evidence pack documents `terraform plan`/`apply`, `-auto-approve`, `-out`, and JSON output flags, but nowhere mentions the `-target` or `-exclude` flags that let a platform engineer scope plan/apply to specific resources. Without citable evidence for this specific capability, it cannot be credited even though it is plausible for this type of tool.

   ⚑ flag

   OpenTofu✓fullprobed8/10

   OpenTofu explicitly documents the -exclude flag for excluding resources from operations, and -target flag support is implied by drop-in Terraform compatibility plus verified hands-on plan/apply workflows. missing for 10: explicit docs/example for the -target flag itself and independent community confirmation of targeted apply usage.

   • [claimed-docs] “Selectively exclude resources from operations with the -exclude flag. This provides more control during testing and rollouts, allowing you t…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

Ai infra ops

1. ai-native userLet an agent plan and apply with least-privilege credentials and review gates so it cannot make unapproved changes

   weight 2 · round to Terraform
   Terraform~partialclaimed7/10

   Terraform's plan/apply workflow provides a clear review gate (plan preview before apply, manual approval unless -auto-approve is used) and policy-as-code enforcement (Sentinel/OPA-style policies) that can block noncompliant changes, plus a dedicated MCP server giving AI agents structured access to docs, modules, and policies — together these support an agent proposing plans that are policy-checked and gated before apply. However, there's no explicit documentation of least-privilege credential scoping specifically for agent-driven runs (e.g., ephemeral/scoped run credentials tied to an agent identity) or of an agent-specific approval workflow beyond the standard CLI/CLOUD run gates. missing for 10: explicit least-privilege credential/service-account guidance for AI agents, documented agent-specific approval/RBAC workflow, independent hands-on evidence of an agent being blocked by policy gates.

   • [claimed-docs] “The `terraform plan` command creates an execution plan, which lets you preview the changes that Terraform plans to make to your infrastructu…”
   • [claimed-docs] “The `terraform apply` command executes the operations proposed in a Terraform plan.”
   • [claimed-docs] “You can pass the `-auto-approve` option to instruct Terraform to apply the plan without asking for confirmation.”
   • [claimed-docs] “Policies are rules for Terraform runs that let you validate that Terraform plans comply with security rules and best practices.”
   • [claimed-docs] “View and override policy enforcement results in the workspace UI.”
   • [claimed-docs] “The Terraform Model Context Protocol (MCP) server enhances AI models with real-time access to current Terraform provider documentation, modu…”
   • [claimed-docs] “The Terraform Model Context Protocol (MCP) server enhances AI models with real-time access to current Terraform provider documentation, modu…”
   • [claimed-docs] “AI enhancement: Enables more accurate and actionable Terraform configuration generation.”

   proof ↗⚑ flag

   OpenTofu~partialprobed4/10

   OpenTofu's plan/apply separation (saved plan files, machine-readable JSON output via `tofu show -json`, and exit codes) gives an agent a natural review gate where a human or policy layer can inspect a plan before `apply` executes it, as shown in probes -5/-6/-7 and docs-3/-4/-21. However, there is no evidence of built-in least-privilege credential scoping, RBAC, approval workflows, or a policy-as-code engine (Sentinel/OPA equivalent) enforcing that gate — the review step is only possible via external tooling, not something OpenTofu itself provides. Missing for 10: native policy-as-code/policy enforcement, credential scoping/RBAC features, and any documented approval-gate mechanism tied to identity or role.

   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “developers can use speculative plans to verify the effect of their changes before submitting them for code review”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

Policy

1. devops-leadEnforce policy-as-code checks that block non-compliant infrastructure changes before apply

   weight 3 · round to Terraform
   Terraform~partialclaimed5/10

   Terraform Cloud/Enterprise documents a policy-enforcement feature (Sentinel/OPA-style) that validates plans against security rules and best practices before allowing an apply, which is the core policy-as-code capability a devops-lead would want. However, evidence is a single thin doc reference with no detail on enforcement levels (advisory vs hard-mandatory), no Sentinel/OPA specifics, and no independent or hands-on confirmation that non-compliant changes are actually blocked. missing for 10: detailed docs on enforcement levels and policy language (Sentinel/OPA), hands-on proof of a blocked apply, independent community corroboration of policy gating in practice.

   • [claimed-docs] “Policies are rules for Terraform runs that let you validate that Terraform plans comply with security rules and best practices.”

   proof ↗⚑ flag

   OpenTofu—none0/10

   The evidence pack shows OpenTofu's plan workflow and machine-readable plan JSON output (e.g., opentofu-probe-5, opentofu-probe-6) which could theoretically feed external policy engines, but there is no mention of any built-in or integrated policy-as-code framework (e.g., Sentinel, OPA/Conftest, Checkov) or documented workflow for blocking non-compliant applies. Missing for 10: any policy-as-code engine or gating mechanism, documentation of policy enforcement in CI/CD, and evidence that non-compliant plans are actually blocked before apply.

   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Terraform—none0/10

   While Terraform lets users choose remote backends (e.g., HCP Terraform or self-hosted state stores) per terraform-docs-33, the evidence pack contains no documentation of region/residency selection controls for where Terraform Cloud/HCP or its data is stored. This axis is fair for a product with a hosted SaaS offering (HCP Terraform) that stores state data, so absence of evidence yields 'none' rather than 'na'.

   • [claimed-docs] “We recommend storing state in HCP Terraform or a remote backend to securely store state and collaborate with team members.”

   proof ↗⚑ flag

   OpenTofu—none0/10

   OpenTofu's evidence covers state encryption and backend usage but contains no documentation or claims about choosing a storage region/data-residency for state or configuration data. While backend configuration (e.g., S3) inherently involves region settings, none of the evidence addresses residency controls as a feature.

   ⚑ flag

2. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Terraform—none0/10

   No evidence pack items mention telemetry, usage tracking, or an opt-out mechanism for Terraform CLI; this is a plausible axis for a CLI tool but no documentation addresses it.

   ⚑ flag

   OpenTofu—none0/10

   No evidence in the pack addresses telemetry, usage tracking, or an opt-out mechanism for OpenTofu; the axis is plausible for a CLI tool but nothing documents it.

   ⚑ flag

Languages

1. developerDefine infrastructure in a general-purpose programming language with types, loops, and IDE support

   weight 2 · round drawn
   Terraform—none0/10

   All evidence describes Terraform's native configuration language (HCL) as a 'human-readable configuration file' language, not a general-purpose programming language with types/loops in the sense of Python/TypeScript; there is no CDKTF or similar general-purpose-language authoring mentioned anywhere in the pack. Community feedback even criticizes it as 'the awful half-baked language,' reinforcing that Terraform's core authoring experience is a declarative DSL rather than a GPL with IDE-native type/loop support.

   • [claimed-docs] “define both cloud and on-prem resources in human-readable configuration files that you can version, reuse, and share”
   • [claimed-docs] “HashiCorp Terraform is an infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration …”
   • [community] “I hate Terraform with a passion but it is probably the best tool out there for managing cloud infrastructure... The biggest downsides are th…”
   • [community] “So, v1.0, but still no dynamic providers, resulting in piles of copypasta especially when creating Kubernetes clusters. Secrets are still st…”

   proof ↗⚑ flag

   OpenTofu—none0/10

   OpenTofu's evidence pack only shows HCL-based declarative configuration (for_each loops, dynamic provider blocks) rather than a general-purpose programming language with types and IDE support; there is no mention of a CDK-like SDK (e.g., TypeScript/Python bindings) that would satisfy this story.

   ⚑ flag

Modules

1. developerConsume and publish reusable modules or components from a public registry

   weight 3 · round to Terraform
   Terraform✓fullclaimed9/10

   Terraform's public Registry explicitly supports publishing and consuming providers, modules, and policies, and modules are a core reusable/versioned configuration primitive documented extensively. missing for 10: independent hands-on evidence of publishing workflow specifics or community friction reports about registry publishing itself.

   • [claimed-docs] “Anyone can publish and consume providers, modules, and policies on the public Terraform Registry.”
   • [claimed-docs] “Anyone can publish and consume providers, modules, and policies on the public Terraform Registry”
   • [claimed-docs] “Create reusable configurations with modules.”
   • [claimed-docs] “HashiCorp Terraform is an infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration …”

   proof ↗⚑ flag

   OpenTofu~partialclaimed6/10

   OpenTofu's docs highlight a large public registry (23,600+ modules) and version-controlled module usage (opentofu-docs-13, opentofu-docs-24, opentofu-docs-12), confirming module consumption is core to the product. However, there is no direct evidence describing a publishing workflow for modules to the registry (e.g., versioning/publish CLI or registry submission process). missing for 10: explicit publish/versioning workflow documentation, independent confirmation of registry usability, and any hands-on evidence of publishing a module.

   • [claimed-docs] “With a thriving ecosystem of 3,900+ providers and 23,600+ modules, you can build and manage infrastructure across every cloud platform with …”
   • [claimed-docs] “With a thriving ecosystem of **3,900+ providers** and **23,600+ modules**, you can build and manage infrastructure across every cloud platfo…”
   • [claimed-docs] “Update all your modules programmatically with a single variable change. Never miss updating a module version by accident - keep your infrast…”

   proof ↗⚑ flag

Providers

1. developerManage resources across all major clouds and SaaS providers through a broad provider ecosystem

   weight 3 · round drawn
   Terraform✓fullcommunity9/10

   Terraform's core value proposition is a broad provider ecosystem via the public Terraform Registry, letting anyone publish/consume providers and modules across clouds, on-prem, and SaaS, with community evidence corroborating real-world multi-cloud/cross-account use cases. missing for 10: independent quantitative data on registry breadth (e.g., number of providers) and no direct evidence contradicting ecosystem breadth.

   • [claimed-docs] “Automate Infrastructure on Any Cloud”
   • [claimed-docs] “Anyone can publish and consume providers, modules, and policies on the public Terraform Registry.”
   • [claimed-docs] “Anyone can publish and consume providers, modules, and policies on the public Terraform Registry”
   • [claimed-docs] “You can also [write your own](/terraform/plugin).”
   • [community] “I recently had to do a piece of AWS work that required cross-account resources... AWS CDK and CloudFormation can't handle that as one step..…”
   • [claimed-docs] “HashiCorp Terraform is an infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration …”

   proof ↗⚑ flag

   OpenTofu✓fullcommunity9/10

   OpenTofu explicitly claims a large provider/module ecosystem (3,900+ providers, 23,600+ modules) covering every major cloud, and being Terraform-compatible means it inherits the entire Terraform provider registry ecosystem; community evidence corroborates drop-in compatibility and easy migration. Missing for 10: independent third-party audit of provider parity/coverage beyond vendor-stated numbers.

   • [claimed-docs] “With a thriving ecosystem of 3,900+ providers and 23,600+ modules, you can build and manage infrastructure across every cloud platform with …”
   • [claimed-docs] “With a thriving ecosystem of **3,900+ providers** and **23,600+ modules**, you can build and manage infrastructure across every cloud platfo…”
   • [claimed-docs] “It serves as a drop-in replacement for Terraform, preserving your existing workflows and configurations.”
   • [community] “Fortunately using OpenTofu is just s/terraform/opentofu/g at this point.”
   • [community] “The move towards OpenTofu is going to be a slow tide, but it is coming. It's an easy migration... We made the jump for one client, started a…”

   proof ↗⚑ flag

Config stacks

1. developerManage per-environment configuration (dev, staging, prod) as separate stacks or workspaces

   weight 2 · round drawn
   Terraform~partialclaimed5/10

   Terraform's state and module system (terraform-docs-20, terraform-docs-33, terraform-docs-13) supports separating configuration into reusable modules and remote state per environment, which is the underlying mechanism for dev/staging/prod separation, but the evidence pack never explicitly documents the `terraform workspace` command or a documented pattern for separate environment stacks. Missing for 10: explicit docs on `terraform workspace new/select`, guidance on directory-per-environment or workspace-per-environment patterns, and independent confirmation of how teams structure environments.

   • [claimed-docs] “Terraform uses your workspace's state to map real world resources to your configuration, keep track of metadata, and to improve performance …”
   • [claimed-docs] “We recommend storing state in HCP Terraform or a remote backend to securely store state and collaborate with team members.”
   • [claimed-docs] “Create reusable configurations with modules.”
   • [claimed-docs] “Terraform provides the terraform state command to perform basic modifications of the state using the CLI.”

   proof ↗⚑ flag

   OpenTofu~partialclaimed5/10

   OpenTofu's docs explicitly mention using for_each to build 'multi-environment setups (dev/staging/prod)' via provider configuration generation, showing the product can model separate environments, and its drop-in Terraform compatibility implies inherited workspace/state-separation mechanisms. However, there is no direct documentation or probe evidence of a dedicated `tofu workspace` command, backend workspace isolation, or a 'stacks' feature being exercised, so the core mechanism developers would use for per-environment config isn't concretely demonstrated. Missing for 10: explicit `tofu workspace` command docs, evidence of stacks/state isolation per environment, and hands-on proof of switching environments.

   • [claimed-docs] “Dynamically generate provider configurations with for_each, eliminating repetitive code and improving maintainability. Perfect for multi-reg…”
   • [claimed-docs] “It serves as a drop-in replacement for Terraform, preserving your existing workflows and configurations.”
   • [claimed-docs] “It serves as a **drop-in replacement for Terraform**, preserving your existing workflows and configurations.”

   proof ↗⚑ flag

Secrets

1. developerPass secrets and sensitive configuration into deployments without exposing them in code or logs

   weight 3 · round to OpenTofu
   Terraform—none0/10

   The evidence pack contains no documentation of Terraform's sensitive-variable marking, environment-variable injection, or secret-manager integrations that would let a developer pass secrets without exposing them in code or logs. The only related evidence is a community comment noting secrets are stored unencrypted in state (terraform-comm-3), which points to a gap rather than a documented capability.

   • [community] “So, v1.0, but still no dynamic providers, resulting in piles of copypasta especially when creating Kubernetes clusters. Secrets are still st…”

   proof ↗⚑ flag

   OpenTofu~partialcommunity5/10

   OpenTofu supports encrypting state and plan files at rest (including AES-GCM configuration) so secrets don't leak in stored state/plan artifacts, and it is Terraform-compatible with variable-based configuration that supports sensitive input passing patterns. However, there is no direct documentation on marking variables as sensitive to suppress console/log output, no evidence of secret-manager integrations, and community commentary raises unresolved concerns about safety of checked-in encrypted state. missing for 10: explicit sensitive-variable/log-redaction documentation, secrets-manager/vault integration evidence, independent verification that logs never expose secret values.

   • [claimed-docs] “OpenTofu supports encrypting state and plan files at rest, both for local storage and when using a backend.”
   • [claimed-docs] “Configure AES-GCM encryption method”
   • [claimed-docs] “OpenTofu supports encrypting state and plan files at rest, both for local storage and when using a backend. In addition, you can also use en…”
   • [community] “I'm very excited for state encryption though! Wondering how safe it is to check an encrypted state file into a public GitHub repo.”

   proof ↗⚑ flag

Drift

1. platform-engineerDetect drift between my declared configuration and the actual cloud resources

   weight 3 · round drawn
   Terraform✓fullcommunity8/10

   Terraform's plan command (and underlying refresh) explicitly compares declared configuration against real infrastructure state to preview differences, which is the core drift-detection mechanism, and terraform show -json / state commands expose that comparison programmatically; community commentary corroborates execution plans as a trusted way to see what will change before applying. Missing for 10: explicit vendor documentation using the term 'drift detection' or a dedicated drift-detection guide, and independent hands-on verification of drift-detection accuracy at scale.

   • [claimed-docs] “creates an execution plan, which lets you preview the changes that Terraform plans to make to your infrastructure”
   • [claimed-docs] “The `terraform plan` command creates an execution plan, which lets you preview the changes that Terraform plans to make to your infrastructu…”
   • [claimed-docs] “Terraform uses your workspace's state to map real world resources to your configuration, keep track of metadata, and to improve performance …”
   • [claimed-docs] “terraform show -json shows a JSON representation of the plan, configuration, and current state”
   • [claimed-docs] “the `terraform show` command provides human-readable output from a state or plan file... Add the `-json` command-line flag to generate machi…”
   • [community] “Terraform has a feature that is critical for safely iterating infrastructure: execution plans. Execution plans show you what changes Terrafo…”

   proof ↗⚑ flag

   OpenTofu✓fullprobed8/10

   OpenTofu's `tofu plan` explicitly supports a refresh-only mode that updates state to reflect out-of-band changes without applying corrections, which is the canonical drift-detection workflow, and a hands-on probe confirms plan surfaces detected changes via -detailed-exitcode in a real run. Missing for 10: an explicit end-to-end hands-on test showing detection of an externally-modified resource (drift) specifically, and independent/community validation of drift detection accuracy.

   • [claimed-docs] “Refresh-only mode: creates a plan whose goal is only to update the OpenTofu state and any root module output values to match changes made to…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”

   proof ↗⚑ flag

State backends

1. platform-engineerStore state in a remote backend with locking so concurrent runs cannot corrupt it

   weight 3 · round drawn
   Terraform—none0/10

   The evidence pack only covers generic `terraform state` CLI commands and local state mapping (terraform-docs-6, terraform-docs-20) plus a community complaint about setting up backend state (terraform-comm-5) — none of it documents remote backends, state locking, or concurrent-run protection. Missing for 10: any docs/tests referencing S3/Consul/Terraform Cloud remote backends, state locking mechanism, or a hands-on probe demonstrating locking prevents concurrent corruption.

   • [claimed-docs] “Terraform provides the terraform state command to perform basic modifications of the state using the CLI.”
   • [claimed-docs] “Terraform uses your workspace's state to map real world resources to your configuration, keep track of metadata, and to improve performance …”
   • [community] “I enjoy Terraform, I just wish there was a more graceful way of setting up a new module to use backend state from the get-go. Having to crea…”
   • [community] “So, v1.0, but still no dynamic providers, resulting in piles of copypasta especially when creating Kubernetes clusters. Secrets are still st…”

   proof ↗⚑ flag

   OpenTofu—none0/10

   The evidence pack covers plan/apply/destroy workflows and state encryption, but contains no mention of remote backends, state locking, or concurrent-run protection. Missing for 10: any documentation or probe evidence of remote backend configuration (e.g., S3/consul/etc.), locking mechanism, or verification that concurrent runs are prevented from corrupting state.

   • [claimed-docs] “OpenTofu supports encrypting state and plan files at rest, both for local storage and when using a backend.”
   • [claimed-docs] “OpenTofu supports encrypting state and plan files at rest, both for local storage and when using a backend. In addition, you can also use en…”

   proof ↗⚑ flag

2. devops-leadEncrypt state at rest so credentials and sensitive values are not readable in plaintext state files

   weight 2 · round to OpenTofu
   Terraform—none0/10

   The evidence pack contains no documentation of a Terraform state encryption-at-rest feature, and community evidence explicitly states 'Secrets are still stored in the state without encryption when retrieving them from the CLI' (terraform-comm-3), indicating this capability is not delivered per the provided evidence.

   • [community] “So, v1.0, but still no dynamic providers, resulting in piles of copypasta especially when creating Kubernetes clusters. Secrets are still st…”
   • [claimed-docs] “Terraform uses your workspace's state to map real world resources to your configuration, keep track of metadata, and to improve performance …”
   • [claimed-docs] “Terraform provides the terraform state command to perform basic modifications of the state using the CLI.”

   proof ↗⚑ flag

   OpenTofu✓fullcommunity9/10

   OpenTofu docs explicitly state built-in state and plan file encryption at rest, for both local and backend storage, with configurable methods like AES-GCM, directly addressing the story. Community sentiment even highlights excitement specifically about this state encryption feature, though the same commenter raises open questions about best practices for encrypted state handling (not a contradiction of the capability itself). missing for 10: independent hands-on verification/probe of the encryption feature actually working (only docs cited, no probe test like the plan/apply probes).

   • [claimed-docs] “OpenTofu supports encrypting state and plan files at rest, both for local storage and when using a backend.”
   • [claimed-docs] “Configure AES-GCM encryption method”
   • [claimed-docs] “OpenTofu supports encrypting state and plan files at rest, both for local storage and when using a backend. In addition, you can also use en…”
   • [community] “I'm very excited for state encryption though! Wondering how safe it is to check an encrypted state file into a public GitHub repo.”

   proof ↗⚑ flag

3. platform-engineerSafely inspect and modify state — moving, removing, or renaming resources — when refactoring

   weight 2 · round to Terraform
   Terraform✓fullclaimed7/10

   Terraform explicitly documents `terraform state` subcommands for basic state modifications (mv/rm/import equivalents) plus `terraform import` for bringing existing resources under management, directly supporting safe state refactoring. missing for 10: no explicit mention of `moved`/`removed` config blocks or `terraform state mv/rm` command details, and no independent/hands-on evidence confirming safe refactoring workflows in practice.

   • [claimed-docs] “Terraform provides the terraform state command to perform basic modifications of the state using the CLI.”
   • [claimed-docs] “Terraform uses your workspace's state to map real world resources to your configuration, keep track of metadata, and to improve performance …”
   • [claimed-docs] “You can import an existing resource to state from the Terraform CLI.”
   • [claimed-docs] “This topic provides an overview of the Terraform commands that let you import existing infrastructure resources so that you can manage them …”
   • [claimed-docs] “We recommend storing state in HCP Terraform or a remote backend to securely store state and collaborate with team members.”

   proof ↗⚑ flag

   OpenTofu~partialclaimed3/10

   The evidence pack shows related state-adjacent capabilities—`tofu import` for bringing existing resources into state, refresh-only mode for reconciling state with real infrastructure, and state encryption—but never documents the actual state-surgery commands (e.g., `tofu state mv`, `tofu state rm`, `moved` blocks) that platform engineers use for refactoring resource addresses. Missing for 10: explicit docs/examples of `state mv`/`state rm`/`moved` block workflows, safety guardrails (backups, dry-run) during state edits, and any hands-on/independent confirmation these operations work reliably.

   • [claimed-docs] “Refresh-only mode: creates a plan whose goal is only to update the OpenTofu state and any root module output values to match changes made to…”
   • [claimed-docs] “The `tofu import` command imports existing resources into OpenTofu.”
   • [claimed-docs] “OpenTofu supports encrypting state and plan files at rest, both for local storage and when using a backend.”

   proof ↗⚑ flag

Testing

1. developerWrite automated tests for my infrastructure code and run them without touching production

   weight 2 · round to Terraform
   Terraform✓fullclaimed8/10

   Terraform has a dedicated `terraform test` framework (terraform-docs-7, -21, -27, -28) that runs tests against test-specific, short-lived resources, explicitly preventing risk to existing infrastructure/state, and even supports mocking provider data so tests can run without touching real infrastructure. This directly satisfies writing automated infra tests without touching production. missing for 10: independent/hands-on evidence of `terraform test` execution (the probes only cover plan/apply/destroy, not the test framework itself), and more detail on CI integration patterns for the test command.

   • [claimed-docs] “Terraform tests let authors validate that module configuration updates do not introduce breaking changes. Tests run against test-specific, s…”
   • [claimed-docs] “Terraform tests let authors validate that module configuration updates do not introduce breaking changes.”
   • [claimed-docs] “Terraform tests let authors validate that module configuration updates do not introduce breaking changes. Tests run against test-specific, s…”
   • [claimed-docs] “Terraform v1.7.0 introduced the ability to mock data returned by the providers during a `terraform test` execution.”

   proof ↗⚑ flag

   OpenTofu~partialclaimed6/10

   OpenTofu ships a native `tofu test` command that creates real infrastructure, checks assertions, then destroys it — directly enabling automated infra tests without touching production, and `tofu plan` speculative plans support pre-review verification. Evidence is first-party docs only with no independent/hands-on corroboration of the test framework's mocking or unit-test capabilities. missing for 10: independent/hands-on validation of `tofu test`, details on mock providers or isolated test environments, community confirmation of test workflow reliability.

   • [claimed-docs] “The `tofu test` command lets you test your OpenTofu configuration by creating real infrastructure and checking that the required conditions …”
   • [claimed-docs] “The `tofu test` command lets you test your OpenTofu configuration by creating real infrastructure and checking that the required conditions …”
   • [claimed-docs] “developers can use speculative plans to verify the effect of their changes before submitting them for code review”
   • [claimed-docs] “This ensures that `.tofu` files always take precedence over `.tf` files when both are available. This scenario can be useful for module auth…”

   proof ↗⚑ flag

2. developerValidate and auto-format my configuration before planning

   weight 1 · round drawn
   Terraform—none0/10

   The evidence pack never mentions `terraform validate` or `terraform fmt`, the actual commands for config validation and auto-formatting. Closest evidence (terraform tests, policy enforcement) address post-write module testing and plan compliance, not pre-plan syntax validation/formatting, so the specific story is unevidenced.

   ⚑ flag

   OpenTofu—none0/10

   The evidence pack covers plan, apply, test, import, and encryption commands but contains no mention of `tofu validate` or `tofu fmt` (or any auto-formatting/validation capability), so there is no evidence supporting this specific story despite the axis clearly applying to a Terraform-compatible IaC CLI. Missing for 10: any doc or probe evidence of a validate command, a fmt/auto-format command, or their integration into a pre-plan workflow.

   ⚑ flag