Terraform vs Pulumi

Agent access

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

   weight 2 · round to Pulumi
   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

   Pulumi✓fullprobed8/10

   A direct probe confirms Pulumi serves a working llms.txt at https://www.pulumi.com/llms.txt (HTTP 200) with a concise agent-oriented summary, and Pulumi also maintains extensive agent-oriented docs (MCP server docs, CLI docs) that AI assistants can be pointed at. missing for 10: independent/community confirmation that agents successfully consume llms.txt in practice, and a docs.md/markdown-flavored docs endpoint (which returned 404).

   • [probe] “PROBE llms.txt: HTTP 200 at https://www.pulumi.com/llms.txt # Pulumi > Infrastructure as code in real programming languages. Define, deploy…”
   • [claimed-docs] “Pulumi’s MCP server implementation provides AI assistants with the ability to: Query your Pulumi Cloud stacks and their resources, Search ac…”
   • [claimed-docs] “The Pulumi Model Context Protocol (MCP) server enables AI-powered coding assistants to access your Pulumi Cloud resources, generate infrastr…”
   • [probe] “official MCP server documented at https://www.pulumi.com/docs/ai/mcp-server/”

   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

   Pulumi✓fullprobed9/10

   Pulumi's CLI supports non-interactive flags and JSON output for scripted use, plus an Automation API explicitly designed for running Pulumi programs without the CLI in orchestration/CI contexts; hands-on probes confirm `pulumi preview/up/destroy --non-interactive` work headlessly on a local backend without Pulumi Cloud, and VCS integrations (GitHub/GitLab/Azure DevOps) support CI pipelines. Missing for 10: no first-party CI-specific documentation (e.g., GitHub Actions workflow examples) or independent CI-pipeline case study in the evidence pack.

   • [claimed-docs] “The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”
   • [claimed-docs] “Connect Pulumi with GitHub, GitLab, and Azure DevOps using Pulumi-maintained version control integrations.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Pulumi
   Terraform✓fullprobed8/10

   Terraform is not itself an agent but an IaC platform, and HashiCorp documents an official Terraform MCP server that gives AI models real-time access to provider docs, modules, and policies, confirmed by both docs and a probe hit. missing for 10: independent/hands-on third-party verification of the MCP server in production use and details on its transport/auth setup.

   • [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] “official MCP server documented at https://developer.hashicorp.com/terraform/mcp-server”

   proof ↗⚑ flag

   Pulumi✓fullprobed9/10

   Pulumi ships an official, documented MCP server (@pulumi/mcp-server) that exposes Pulumi Cloud stacks/resources and CLI commands to AI assistants like Cursor, Claude Code/Desktop, and Windsurf, and a hands-on probe confirms it actually performs a JSON-RPC MCP handshake and responds correctly. Missing for 10: no independent third-party (non-Pulumi) review of the MCP server's real-world reliability/behavior beyond the single probe.

   • [claimed-docs] “Pulumi’s MCP server implementation provides AI assistants with the ability to: Query your Pulumi Cloud stacks and their resources, Search ac…”
   • [claimed-docs] “The Pulumi MCP server works with various AI-powered development tools: **Cursor**...**Anthropic’s Claude Code**...**Windsurf**...**Claude De…”
   • [claimed-docs] “The Pulumi Model Context Protocol (MCP) server enables AI-powered coding assistants to access your Pulumi Cloud resources, generate infrastr…”
   • [probe] “official MCP server documented at https://www.pulumi.com/docs/ai/mcp-server/”
   • [probe] “PROBE mcp-handshake (local run): the official Pulumi MCP server (`npx @pulumi/mcp-server@latest stdio`, v0.2.0) answered a JSON-RPC initiali…”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Pulumi
   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

   Pulumi✓fullprobed9/10

   Pulumi ships an official CLI with documented commands (preview, up, import, destroy) and hands-on probes confirm it runs headlessly with structured JSON output an agent can parse, plus non-interactive/automated flags well suited to AI-native workflows. Missing for 10: no independent third-party review specifically praising the CLI's AI-native ergonomics beyond the vendor probes.

   • [probe] “official CLI documented at https://www.pulumi.com/docs/iac/cli/”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”
   • [claimed-docs] “you run `pulumi import` against a specific cloud resource. Pulumi adds the resource to your stack’s state and generates the code needed to m…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   Pulumi~partialprobed6/10

   Pulumi offers a documented Automation API (programmatic, language-based interface) and a verified MCP server (probed handshake works) plus a CLI with JSON output, giving AI-native users multiple programmatic ways to drive it. However, there is no true public REST/OpenAPI API (openapi.json/swagger endpoints all 404) and no llms.txt-driven docs-md endpoint, so 'documented public API' in the traditional sense is unconfirmed. missing for 10: a documented REST/OpenAPI-style public API, independent third-party corroboration of Automation API usage, and confirmation that MCP/Automation API cover full CRUD parity with the CLI.

   • [claimed-docs] “The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI.”
   • [claimed-docs] “Pulumi’s MCP server implementation provides AI assistants with the ability to: Query your Pulumi Cloud stacks and their resources, Search ac…”
   • [claimed-docs] “The Pulumi Model Context Protocol (MCP) server enables AI-powered coding assistants to access your Pulumi Cloud resources, generate infrastr…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.pulumi.com/openapi.json, https://www.pulumi.com/swagger.json, https://www.pulumi.com/api…”
   • [probe] “official MCP server documented at https://www.pulumi.com/docs/ai/mcp-server/”
   • [probe] “PROBE mcp-handshake (local run): the official Pulumi MCP server (`npx @pulumi/mcp-server@latest stdio`, v0.2.0) answered a JSON-RPC initiali…”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round drawn
   Terraform—none0/10

   No evidence that Terraform (or its MCP server) supports issuing scoped/least-privilege API credentials for an agent; credential/auth scoping is typically delegated to cloud provider IAM, and nothing in the docs describes Terraform generating or managing agent-specific least-privilege credentials.

   • [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”

   proof ↗⚑ flag

   Pulumi—none0/10

   The evidence covers Pulumi's MCP server for AI agent integration and CLI/API access broadly, but nothing describes issuing scoped or least-privilege API credentials/tokens specifically for an agent's use (e.g., token scoping, RBAC-limited service accounts, or credential minting for AI agents). This is a fair question for a cloud IaC platform with an API/token system, but no evidence supports it.

   ⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Pulumi
   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

   Pulumi✓fullprobed9/10

   Pulumi provides official SDKs across multiple mainstream languages (TypeScript, Python, Go, .NET, Java, YAML) with full provider surface area, plus an Automation API for programmatic use and a documented, hands-on-verified MCP server enabling AI assistants to interact with Pulumi programs. This is strongly corroborated by official docs and a live probe confirming the MCP server handshake works. Missing for 10: independent third-party (non-vendor) benchmarking of SDK completeness/parity across all languages, and no evidence of official SDKs in additional languages like Rust or Java-adjacent ecosystems beyond what's listed.

   • [claimed-docs] “Pulumi supports TypeScript, JavaScript, Python, Go, .NET, Java, YAML, and HCL. Each language is equally capable and supports the full surfac…”
   • [claimed-docs] “The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI.”
   • [claimed-docs] “Pulumi supports TypeScript, JavaScript, Python, Go, .NET, Java, YAML, and HCL.”
   • [claimed-docs] “The Pulumi Model Context Protocol (MCP) server enables AI-powered coding assistants to access your Pulumi Cloud resources, generate infrastr…”
   • [claimed-docs] “The Pulumi MCP server works with various AI-powered development tools: **Cursor**...**Anthropic’s Claude Code**...**Windsurf**...**Claude De…”
   • [probe] “official MCP server documented at https://www.pulumi.com/docs/ai/mcp-server/”
   • [probe] “PROBE mcp-handshake (local run): the official Pulumi MCP server (`npx @pulumi/mcp-server@latest stdio`, v0.2.0) answered a JSON-RPC initiali…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Terraform—none0/10

   No evidence of webhook subscription capability for events in Terraform's core product; while Terraform Cloud has run notifications/webhooks in some contexts, nothing in this evidence pack documents a webhook subscription mechanism for AI-native event consumption. Terraform is fundamentally an IaC provisioning tool, so this axis could apply but is unevidenced.

   ⚑ flag

   Pulumi—none0/10

   No evidence in the pack mentions webhooks or event subscriptions of any kind; Pulumi's AI-facing integrations documented are MCP server access and Automation API, not webhook-based event subscription. missing for 10: any documentation or mention of webhook support, event subscription APIs, or notification triggers.

   ⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to Pulumi
   Terraform—none0/10

   Evidence only shows an MCP server that lets external AI models query Terraform docs/modules/policies for building configurations — this is agentic tool access, not Terraform itself generating insights or suggestions from a user's own infrastructure data. No documentation shows in-product AI analysis (e.g., cost/security recommendations, drift insights) surfaced to users.

   • [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.”

   proof ↗⚑ flag

   Pulumi~partialcommunity6/10

   Pulumi's 'Insights' policy features and Neo agent provide some AI-driven analysis of infrastructure (policy guardrails, plain-English task delegation), and the MCP server lets AI assistants query/search cloud resources, but there is no dedicated in-product 'insights/suggestions' dashboard shown generating proactive AI analysis of a user's own data beyond policy compliance and Neo's provisioning actions; one community report calls Pulumi's genAI documentation poor. missing for 10: concrete evidence of an in-product AI insights/dashboard analyzing existing resource data and generating proactive suggestions (not just policy enforcement or Neo's task execution), and independent corroboration of quality.

   • [claimed-docs] “Pulumi Policies enables you to implement policy as code across your entire cloud infrastructure. You define guardrails in code and apply the…”
   • [claimed-docs] “Neo provisions, governs, and optimizes your cloud infrastructure — with enterprise controls built in.”
   • [claimed-docs] “Tell Neo what you need in plain English. It handles dependencies, executes changes, and monitors outcomes automatically.”
   • [claimed-docs] “The Pulumi Model Context Protocol (MCP) server enables AI-powered coding assistants to access your Pulumi Cloud resources, generate infrastr…”
   • [community] “Pulumi genAI-based documentation is trashed. I've moved to terraform and i was able to achieve much better results in shorter time thanks to…”

   proof ↗⚑ flag

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

   weight 2 · round to Pulumi
   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

   Pulumi~partialprobed6/10

   Pulumi documents both an Automation API for embedding Pulumi programs into custom background services (pulumi-docs-2) and 'Neo', an agent described as autonomously provisioning, governing, and optimizing infrastructure from plain-English instructions (pulumi-docs-9, pulumi-docs-20), plus headless CLI runs confirmed via probe (pulumi-probe-6, pulumi-probe-7). However, Neo's autonomous background operation is only vendor marketing copy with no hands-on or independent verification, and Automation API requires the user to build their own scheduling/triggering layer rather than shipping a ready background-automation feature. Missing for 10: hands-on/independent evidence Neo (or another built-in scheduler) actually runs unattended in production, native trigger/schedule primitives beyond Automation API, and community corroboration of autonomous operation.

   • [claimed-docs] “The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI.”
   • [claimed-docs] “Neo provisions, governs, and optimizes your cloud infrastructure — with enterprise controls built in.”
   • [claimed-docs] “Tell Neo what you need in plain English. It handles dependencies, executes changes, and monitors outcomes automatically.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Pulumi
   Terraform—none0/10

   Evidence shows an MCP server that lets external AI models query Terraform docs/modules/policies, but this is Terraform acting as a server for outside agents, not a built-in assistant inside the product that a user can delegate tasks to. No documentation or probe shows an in-product AI assistant/chat feature.

   ⚑ flag

   Pulumi✓fullclaimed6/10

   Pulumi ships 'Neo', a built-in AI agent described as taking plain-English infrastructure requests and autonomously handling dependencies, executing changes, and monitoring outcomes, and the MCP docs explicitly note tasks can be delegated to Neo. This directly matches the story of delegating tasks to an in-product AI assistant. Missing for 10: independent or hands-on verification of Neo's actual task execution/autonomy (only vendor docs), and detail on scope/guardrails of what Neo can do unsupervised.

   • [claimed-docs] “Neo provisions, governs, and optimizes your cloud infrastructure — with enterprise controls built in.”
   • [claimed-docs] “Tell Neo what you need in plain English. It handles dependencies, executes changes, and monitors outcomes automatically.”
   • [claimed-docs] “The Pulumi Model Context Protocol (MCP) server enables AI-powered coding assistants to access your Pulumi Cloud resources, generate infrastr…”

   proof ↗⚑ flag

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

   weight 2 · round to Pulumi
   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

   Pulumi~partialprobed7/10

   Pulumi Neo is explicitly marketed to accept plain-English infrastructure requests ('Tell Neo what you need in plain English...') and the official MCP server, verified hands-on via JSON-RPC handshake, lets AI assistants translate natural-language prompts into Pulumi CLI/registry operations. However, Neo's NL capability is only vendor-claimed (no hands-on or community verification) and is a separate enterprise product, while the core Pulumi CLI itself remains code/command-driven, not NL-native. Missing for 10: independent or hands-on verification of Neo's natural-language handling, and evidence that natural-language control works without relying on Neo or an external AI coding assistant via MCP.

   • [claimed-docs] “Neo provisions, governs, and optimizes your cloud infrastructure — with enterprise controls built in.”
   • [claimed-docs] “Tell Neo what you need in plain English. It handles dependencies, executes changes, and monitors outcomes automatically.”
   • [claimed-docs] “The Pulumi Model Context Protocol (MCP) server enables AI-powered coding assistants to access your Pulumi Cloud resources, generate infrastr…”
   • [claimed-docs] “The Pulumi MCP server works with various AI-powered development tools: **Cursor**...**Anthropic’s Claude Code**...**Windsurf**...**Claude De…”
   • [probe] “PROBE mcp-handshake (local run): the official Pulumi MCP server (`npx @pulumi/mcp-server@latest stdio`, v0.2.0) answered a JSON-RPC initiali…”

   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

   Pulumi—none0/10

   No evidence of an interactive API reference with runnable examples; probes explicitly show no OpenAPI/Swagger spec (404s across candidate paths) and no mention of a live/sandboxed API explorer. Pulumi's docs describe language SDKs and CLI commands but not an interactive, runnable API reference.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.pulumi.com/openapi.json, https://www.pulumi.com/swagger.json, https://www.pulumi.com/api…”
   • [claimed-docs] “Pulumi supports TypeScript, JavaScript, Python, Go, .NET, Java, YAML, and HCL.”

   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

   Pulumi—none0/10

   A direct probe for an OpenAPI/equivalent spec at all standard candidate paths returned 404 across the board, and no evidence pack item shows Pulumi publishing a downloadable machine-readable API spec; the llms.txt found is a marketing/context file, not an API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.pulumi.com/openapi.json, https://www.pulumi.com/swagger.json, https://www.pulumi.com/api…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://www.pulumi.com/llms.txt # Pulumi > Infrastructure as code in real programming languages. Define, deploy…”

   proof ↗⚑ flag

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

   weight 1 · round to Pulumi
   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

   Pulumi~partialprobed7/10

   Pulumi's testing docs describe integration tests that 'deploy ephemeral infrastructure and run external tests against it' and preview command that makes 'no changes to the stack,' and probes confirm a full headless up/destroy loop against a local file backend without touching Pulumi Cloud or production state. This supports safe sandbox testing, but the evidence never explicitly describes stack-based prod/sandbox isolation or guardrails preventing accidental production impact from an AI agent. Missing for 10: explicit multi-stack environment isolation guidance, agent-specific guardrails against touching prod stacks, and independent hands-on confirmation of safe sandboxing beyond the vendor-run probe.

   • [claimed-docs] “Unit Tests are fast in-memory tests that mock all external calls. Property Tests run resource-level assertions while infrastructure is being…”
   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”

   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

   Pulumi—none0/10

   No evidence pack item discusses API versioning or a documented deprecation policy for Pulumi's APIs (CLI, SDK, Automation API, or MCP server); the OpenAPI probe returned 404s and no changelog/versioning policy is cited. Community evidence even mentions Pulumi lagging on deprecated Azure resources with no fix, but this is unrelated to a documented deprecation policy for Pulumi's own APIs.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.pulumi.com/openapi.json, https://www.pulumi.com/swagger.json, https://www.pulumi.com/api…”
   • [community] “I like it, but anybody I pitched it to was like: 'Ewww, TypeScript for Infra.' Pulumi for months used deprecated Azure stuff, and they didn'…”

   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

   Pulumi~partialprobed6/10

   Pulumi supports bulk-oriented workflows: pulumi preview --import-file can generate an import covering every resource a program would create, the Automation API allows programmatic orchestration across many stacks or resources, and real-world usage reports deployments of 500+ resources at once. These give an AI agent, via CLI or MCP server, levers for bulk operations, but the docs never explicitly frame a bulk operation across many items workflow for AI agents, and the MCP server evidence only demonstrates single CLI command execution, not batch or bulk semantics. missing for 10: explicit bulk-operation API/CLI docs such as bulk import across many resources in one call or bulk stack updates framed for AI-agent consumption, and hands-on evidence of an agent performing such bulk ops via MCP

   • [claimed-docs] “run `pulumi preview --import-file` to generate an import file listing every resource the program would otherwise create”
   • [claimed-docs] “The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI.”
   • [community] “Using Pulumi for about 1 year to manage gcp and AWS environments (5+) - each deployment is around 500 resources. At the begining it was bugg…”
   • [claimed-docs] “The Pulumi Model Context Protocol (MCP) server enables AI-powered coding assistants to access your Pulumi Cloud resources, generate infrastr…”
   • [probe] “PROBE mcp-handshake (local run): the official Pulumi MCP server (`npx @pulumi/mcp-server@latest stdio`, v0.2.0) answered a JSON-RPC initiali…”

   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

   Pulumi—none0/10

   The evidence covers Pulumi's languages, testing, state backends, policy-as-code guardrails, import, and MCP/Automation API integrations, but none of it describes a mechanism for defining rules that automatically trigger actions in response to events (e.g., webhooks, event-driven pipelines, or reactive automation). Policy as code (pulumi-docs-5/16) enforces guardrails during deployments rather than triggering actions on arbitrary events, and the Automation API (pulumi-docs-2) is for programmatic invocation, not event-driven rule execution.

   • [claimed-docs] “The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI.”
   • [claimed-docs] “Pulumi Policies enables you to implement policy as code across your entire cloud infrastructure. You define guardrails in code and apply the…”
   • [claimed-docs] “You define guardrails in code and apply them consistently across resources managed by Pulumi IaC, provisioned with Terraform or CloudFormati…”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Terraform—none0/10

   The evidence pack covers Terraform's plan/apply/test/state workflow and MCP server for AI documentation lookup, but contains no mention of a scheduler, cron-like trigger, or recurring workflow execution feature (native or via HCP Terraform). Since infrastructure-automation platforms could plausibly offer scheduled/recurring runs, the axis applies, but no evidence supports it.

   ⚑ flag

   Pulumi—none0/10

   Pulumi's evidence shows Automation API for programmatic runs, CLI commands, and Neo for AI-driven provisioning, but nothing describes built-in support for scheduling recurring jobs or workflows (e.g., cron-like triggers, scheduled drift detection, or workflow orchestration). Such a capability is plausible for an IaC/automation platform, so the axis applies, but no evidence confirms it.

   • [claimed-docs] “The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI.”
   • [claimed-docs] “Neo provisions, governs, and optimizes your cloud infrastructure — with enterprise controls built in.”
   • [claimed-docs] “Tell Neo what you need in plain English. It handles dependencies, executes changes, and monitors outcomes automatically.”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   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

   Pulumi~partialprobed6/10

   Pulumi's code-based IaC is inherently versionable via standard VCS (git integrations documented), and `pulumi preview`/`pulumi destroy`/state backends give rollback-like control validated hands-on via CLI probes; policy-as-code adds review guardrails. However there's no dedicated 'automation review' workflow, no built-in diff/approval UI beyond preview output, and community feedback flags documentation/complexity issues around dependency management that complicate confident rollback for AI-driven changes. missing for 10: a first-party automated review/approval gate for AI-initiated changes, explicit rollback command/semantics (vs. re-apply prior state), and independent verification of policy-as-code enforcement in practice.

   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Pulumi Policies enables you to implement policy as code across your entire cloud infrastructure. You define guardrails in code and apply the…”
   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [claimed-docs] “Connect Pulumi with GitHub, GitLab, and Azure DevOps using Pulumi-maintained version control integrations.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”
   • [community] “Pulumi also has a killer Automation feature, where you can code infrastructure migrations, not unlike you'd do for SQL. Neither TF nor CDK a…”
   • [community] “A couple of years ago I started down the Pulumi path... values that are only available in the second phase (eg a subnet ID) can't be accesse…”

   proof ↗⚑ flag

Import

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

   weight 3 · round to Pulumi
   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

   Pulumi✓fullclaimed9/10

   Pulumi provides a documented `pulumi import` command that adopts existing resources into stack state and generates matching code in the target language, plus `pulumi preview --import-file` to bulk-generate import files for existing resources, directly matching the story. Docs explicitly describe this as core migration functionality for resources created manually or by other IaC tools. Missing for 10: independent/hands-on verification of the import workflow itself (only preview/apply loop was probed, not import).

   • [claimed-docs] “Adopting the existing resource to bring it under management by Pulumi... is called adoption or import.”
   • [claimed-docs] “Most infrastructure as code projects require working with existing cloud resources, whether those resources were originally created with ano…”
   • [claimed-docs] “you run `pulumi import` against a specific cloud resource. Pulumi adds the resource to your stack’s state and generates the code needed to m…”
   • [claimed-docs] “run `pulumi preview --import-file` to generate an import file listing every resource the program would otherwise create”
   • [claimed-docs] “Migrate from Terraform, CloudFormation, and other tools.”

   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 Terraform
   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

   Pulumi—none0/10

   The evidence pack contains no mention of Pulumi's license type (e.g., Apache 2.0), its governance model, or any foundation/neutral steward that would prevent unilateral relicensing — only GitHub repo links and generic self-hosting/backend docs. Given the well-known industry concern (post-Terraform BSL) that devops leads would want addressed, this axis clearly applies but no evidence in the pack speaks to license or governance guarantees.

   • [github] “Skip the YAML, and use standard language features like loops, functions, classes, and package management that you already know and love.”
   • [github] “Pulumi automatically provisions and manages your resources on AWS, Azure, Google Cloud Platform, Kubernetes, and 300+ providers”
   • [claimed-docs] “Self-hosting available”

   proof ↗⚑ flag

Stability

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

   weight 2 · round drawn
   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

   Pulumi—none0/10

   The evidence pack contains no documentation of versioning/compatibility promises, deprecation policy, or upgrade guides between Pulumi CLI/SDK releases; the closest items (resource import/adoption docs) address migrating existing cloud resources into Pulumi, not release-to-release compatibility. Missing for 10: any semver/compatibility policy docs, breaking-change/deprecation notices, or dedicated upgrade guides between major versions.

   ⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round drawn
   Terraform~partialprobed5/10

   Terraform's CLI/JSON tooling (terraform plan/apply/show -json, machine-readable UI output, state and import commands) lets automation and AI agents drive nearly every core workflow without the UI, and Terraform Cloud exposes policy results in its workspace UI, implying an underlying API layer. However, there is no direct evidence of a documented, comprehensive REST/OpenAPI spec proving true UI/API parity, and probes for an OpenAPI schema and machine-readable docs all 404, suggesting the API surface for Terraform Cloud's UI-specific features (e.g., policy override, workspace management) isn't clearly documented for AI consumption. missing for 10: explicit Terraform Cloud/Enterprise API docs proving 1:1 parity with UI actions, a discoverable OpenAPI/schema for AI tooling, and confirmation that UI-only actions (like policy overrides) are also API-accessible.

   • [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] “For long-running commands such as `plan`, `apply`, `refresh`, and `test`, the `-json` flag outputs a stream of JSON UI messages.”
   • [claimed-docs] “View and override policy enforcement results in the workspace UI.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.hashicorp.com/openapi.json, https://developer.hashicorp.com/swagger.json, https://…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developer.hashicorp.com/llms.txt”

   proof ↗⚑ flag

   Pulumi~partialprobed5/10

   Pulumi offers a scriptable CLI and Automation API for running programs without the console, and hands-on probes confirm headless preview/up/destroy and MCP server operation work fully outside the UI, but there is no evidence of a full REST/OpenAPI surface (probe found no openapi.json) or explicit documentation that Pulumi Cloud UI features like Insights, Policy dashboards, or Neo's console-only controls are all reachable programmatically. missing for 10: explicit API/CLI parity claim for Pulumi Cloud console features (Insights, Policy management, Neo dashboard), a discoverable OpenAPI/REST spec, and independent confirmation that no UI-only functionality exists.

   • [claimed-docs] “The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”
   • [probe] “PROBE mcp-handshake (local run): the official Pulumi MCP server (`npx @pulumi/mcp-server@latest stdio`, v0.2.0) answered a JSON-RPC initiali…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.pulumi.com/openapi.json, https://www.pulumi.com/swagger.json, https://www.pulumi.com/api…”
   • [claimed-docs] “Neo provisions, governs, and optimizes your cloud infrastructure — with enterprise controls built in.”
   • [claimed-docs] “Pulumi Policies enables you to implement policy as code across your entire cloud infrastructure. You define guardrails in code and apply the…”

   proof ↗⚑ flag

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

   weight 3 · round to Terraform
   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

   Pulumi~partialcommunity5/10

   Pulumi code is written in standard, open programming languages (TS, Python, Go, etc.) rather than a proprietary DSL, and state can be stored in a self-managed 'DIY' backend (S3, Azure Blob, GCS) instead of Pulumi Cloud, giving a path to keep data in open formats and avoid full platform lock-in. However, community evidence notes Pulumi still 'calls into the mothership' for some functionality and there is no documented explicit bulk-export/migration tool for leaving the platform. Missing for 10: dedicated data-export/migration tooling to leave, clear documentation on state file/format portability guarantees, and independent verification that self-hosted deployments have no residual cloud dependency.

   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Pulumi supports two classes of state backend: **Pulumi Cloud**: a managed backend...**DIY backend**: a “Do It Yourself” backend that stores …”
   • [claimed-docs] “Backend options include Pulumi Cloud, an easy-to-use, secure, and reliable hosted application ... in addition to simple object storage in AW…”
   • [claimed-docs] “Self-hosting available”
   • [community] “Last time I checked... Pulumi only works by calling in to the mothership: i.e. you cannot build an airgapped infrastructure with it. This wa…”
   • [github] “Skip the YAML, and use standard language features like loops, functions, classes, and package management that you already know and love.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Pulumi~partialclaimed4/10

   Evidence confirms Pulumi's core CLI/SDK is published on GitHub (pulumi-gh-1, pulumi-gh-2), so an AI-native user could read source there, but the evidence pack never states an explicit open-source license, and Pulumi's cloud/state backend and Neo agent components are proprietary SaaS (pulumi-docs-4, pulumi-docs-9) rather than open source. missing for 10: explicit license text/statement, confirmation that all product components (not just core CLI/SDK) are open, independent confirmation of license terms.

   • [github] “Skip the YAML, and use standard language features like loops, functions, classes, and package management that you already know and love.”
   • [github] “Pulumi automatically provisions and manages your resources on AWS, Azure, Google Cloud Platform, Kubernetes, and 300+ providers”
   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Neo provisions, governs, and optimizes your cloud infrastructure — with enterprise controls built in.”

   proof ↗⚑ flag

4. 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

   Pulumi✓fullprobed8/10

   Pulumi's core engine/CLI is open-source and can run fully locally without any cloud dependency — confirmed hands-on via probes showing `pulumi preview`/`up`/`destroy` running headlessly against a local file:// backend with PULUMI_CONFIG_PASSPHRASE for state encryption (pulumi-probe-6, pulumi-probe-7). Docs further describe a 'DIY backend' storing state in self-managed object storage (S3/Azure Blob/GCS) as an alternative to the hosted Pulumi Cloud (pulumi-docs-4, pulumi-docs-14, pulumi-docs-23), and the pricing page explicitly states 'Self-hosting available' for the broader service (pulumi-docs-27), corroborated by a community note that Pulumi's state service has a self-management option (pulumi-comm-19). missing for 10: detailed first-party documentation of deploying the full self-hosted Pulumi Cloud service (UI/API), and independent hands-on verification of that enterprise self-hosted deployment rather than just the DIY state-backend/local-CLI path.

   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Pulumi supports two classes of state backend: **Pulumi Cloud**: a managed backend...**DIY backend**: a “Do It Yourself” backend that stores …”
   • [claimed-docs] “Backend options include Pulumi Cloud, an easy-to-use, secure, and reliable hosted application ... in addition to simple object storage in AW…”
   • [claimed-docs] “Self-hosting available”
   • [community] “Pulumi maintains its own state service (with option of self management)... As a developer, I quite liked Pulumi resource model, documentatio…”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”

   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

   Pulumi✓fullprobed9/10

   Pulumi's `pulumi preview --json` produces a structured JSON steps[] array (op, urn, etc.) that an agent can parse to reason about a proposed change, and this was independently verified hands-on in a local, non-interactive run without Pulumi Cloud. Documentation and CLI reference corroborate this as an officially supported flag. missing for 10: no independent third-party (non-vendor) documentation of agents actually consuming this JSON for reasoning, only a single hands-on probe.

   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”

   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 Pulumi
   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

   Pulumi✓fullprobed8/10

   Pulumi's Automation API and CLI allow headless plan generation (`pulumi preview --non-interactive --json`) with structured diff output that an agent can parse, and hands-on probes confirm this and the full apply loop work headlessly without Pulumi Cloud; the official MCP server (verified via handshake) lets AI assistants generate infrastructure code and run CLI commands, supporting an agent-authored-and-approved workflow. missing for 10: a single end-to-end demonstrated workflow tying MCP-based code authoring directly into the headless preview/approval loop, and independent (non-vendor) verification of that combined flow.

   • [claimed-docs] “The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”
   • [claimed-docs] “The Pulumi Model Context Protocol (MCP) server enables AI-powered coding assistants to access your Pulumi Cloud resources, generate infrastr…”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”
   • [probe] “PROBE mcp-handshake (local run): the official Pulumi MCP server (`npx @pulumi/mcp-server@latest stdio`, v0.2.0) answered a JSON-RPC initiali…”
   • [claimed-docs] “Pulumi’s MCP server implementation provides AI assistants with the ability to: Query your Pulumi Cloud stacks and their resources, Search ac…”
   • [claimed-docs] “The Pulumi MCP server works with various AI-powered development tools: **Cursor**...**Anthropic’s Claude Code**...**Windsurf**...**Claude De…”

   proof ↗⚑ flag

Automation api

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

   weight 2 · round to Pulumi
   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

   Pulumi✓fullcommunity9/10

   Pulumi's Automation API is explicitly documented as a programmatic interface for running Pulumi programs without the CLI, letting developers drive previews/deploys/destroys directly from application code, and this is corroborated by community mention of coding infra migrations via Automation. missing for 10: independent hands-on verification of the Automation API itself (the probes validate CLI/MCP headless flows but not an actual Automation API SDK call).

   • [claimed-docs] “The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI.”
   • [community] “Pulumi also has a killer Automation feature, where you can code infrastructure migrations, not unlike you'd do for SQL. Neither TF nor CDK a…”

   proof ↗⚑ flag

Plan workflow

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

   weight 2 · round to Pulumi
   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

   Pulumi✓fullprobed9/10

   Pulumi's `pulumi destroy` command is directly evidenced by a hands-on probe showing it exits 0 and cleanly tears down resources after an apply, running headlessly without cloud dependency, confirming the standard destroy workflow works as documented. missing for 10: no independent/community corroboration specifically discussing destroy behavior (only a first-party probe and docs).

   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”
   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [probe] “official CLI documented at https://www.pulumi.com/docs/iac/cli/”

   proof ↗⚑ flag

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

   weight 3 · round to Terraform
   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

   Pulumi~partialprobed6/10

   Evidence confirms Pulumi CLI supports fully non-interactive plan/apply in CI: `pulumi preview --non-interactive --json` and `pulumi up --non-interactive --yes --skip-preview` both ran headlessly with approval flags (--yes) and produced machine-parseable output, per hands-on probes [pulumi-probe-6][pulumi-probe-7], with `pulumi preview` docs confirming plan-only dry-run behavior [pulumi-docs-8][pulumi-docs-19]. However, the pack contains no evidence of the specific 'saved plan artifact' workflow (e.g., generating and re-applying a persisted plan file) that the story calls out, only generic non-interactive preview/apply. Missing for 10: documentation or hands-on proof of saved-plan-artifact generation/application (e.g., --save-plan/--plan flags), and independent (non-vendor) confirmation of this exact CI pattern.

   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”

   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

   Pulumi✓fullprobed9/10

   Pulumi's `pulumi preview` command explicitly shows creates, updates, and destroys without applying any changes, and this was independently verified via hands-on probe producing structured JSON steps[] output that an agent/tool can consume. Docs and probe evidence corroborate this core plan-apply workflow works headlessly. Missing for 10: independent third-party review specifically praising/critiquing preview accuracy in production use (community evidence is about Pulumi generally, not preview diffing specifically).

   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [claimed-docs] “run `pulumi preview --import-file` to generate an import file listing every resource the program would otherwise create”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   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

   Pulumi—none0/10

   No evidence in the pack mentions Pulumi's targeting/exclusion flags (e.g., `--target`, `--exclude`) for `pulumi preview`/`pulumi up`/`pulumi destroy`; the pack only covers preview mechanics, import, and state/backends without addressing resource-scoped plan/apply. missing for 10: documentation or hands-on proof of --target/--exclude (or equivalent) flags limiting a plan/apply to specific resources.

   ⚑ 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

   Pulumi~partialprobed5/10

   Pulumi provides the building blocks — Policy as Code guardrails (pulumi-docs-5/16), a preview/dry-run step that shows changes before they're applied (pulumi-docs-8/19, pulumi-probe-6), and an MCP server letting AI assistants query/generate/delegate infra changes (pulumi-docs-7/18/26, pulumi-probe-8) — but there is no documented mechanism tying an agent's MCP/CLI actions specifically to least-privilege scoped credentials or an explicit human-approval gate before 'pulumi up' executes for agent-initiated changes. Missing for 10: explicit least-privilege credential scoping for agent identities, a documented approval/review workflow gating agent-triggered applies, and evidence the MCP server itself is constrained from calling 'pulumi up' without human sign-off.

   • [claimed-docs] “Pulumi Policies enables you to implement policy as code across your entire cloud infrastructure. You define guardrails in code and apply the…”
   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”
   • [claimed-docs] “Pulumi’s MCP server implementation provides AI assistants with the ability to: Query your Pulumi Cloud stacks and their resources, Search ac…”
   • [claimed-docs] “The Pulumi MCP server works with various AI-powered development tools: **Cursor**...**Anthropic’s Claude Code**...**Windsurf**...**Claude De…”
   • [claimed-docs] “The Pulumi Model Context Protocol (MCP) server enables AI-powered coding assistants to access your Pulumi Cloud resources, generate infrastr…”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE mcp-handshake (local run): the official Pulumi MCP server (`npx @pulumi/mcp-server@latest stdio`, v0.2.0) answered a JSON-RPC initiali…”

   proof ↗⚑ flag

Policy

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

   weight 3 · round to Pulumi
   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

   Pulumi✓fullclaimed8/10

   Pulumi's Policy-as-Code product explicitly lets teams define guardrails in code and apply them consistently across resources managed by Pulumi, Terraform, CloudFormation, or created manually — directly addressing pre-apply compliance enforcement, and this integrates with the CLI's preview/apply workflow to block non-compliant changes before they take effect. Missing for 10: no independent/hands-on evidence of a policy pack actually blocking a non-compliant `pulumi up`, and no detail on CI/CD gating specifics beyond docs claims.

   • [claimed-docs] “Pulumi Policies enables you to implement policy as code across your entire cloud infrastructure. You define guardrails in code and apply the…”
   • [claimed-docs] “You define guardrails in code and apply them consistently across resources managed by Pulumi IaC, provisioned with Terraform or CloudFormati…”
   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”

   proof ↗⚑ flag

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

   weight 2 · round to Pulumi
   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

   Pulumi~partialclaimed5/10

   Pulumi lets users choose a self-managed 'DIY' state backend (AWS S3, Azure Blob Storage, Google Cloud Storage) or self-host, which effectively lets a user pick the storage region/provider for state data, and self-hosting is explicitly offered on the pricing page. However, there is no documented region-selection control for the default Pulumi Cloud managed backend itself, and no explicit data-residency/compliance documentation (e.g., EU-only region option) for AI-native workflows. Missing for 10: explicit region-selection UI/API for Pulumi Cloud's managed backend, documented data-residency guarantees or compliance certifications tied to region choice.

   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Pulumi supports two classes of state backend: **Pulumi Cloud**: a managed backend...**DIY backend**: a “Do It Yourself” backend that stores …”
   • [claimed-docs] “Backend options include Pulumi Cloud, an easy-to-use, secure, and reliable hosted application ... in addition to simple object storage in AW…”
   • [claimed-docs] “Self-hosting available”

   proof ↗⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round to Pulumi
   Terraform—none0/10

   The evidence pack contains no mention of data-retention policies, deletion controls, GDPR/CCPA compliance, or privacy settings for Terraform or HCP Terraform's stored state/logs. State-management docs (terraform state rm, import) address infrastructure resource tracking, not user data privacy controls, so they cannot substitute. missing for 10: any documentation of retention windows, deletion APIs/commands for user or telemetry data, or privacy/compliance policy pages.

   ⚑ flag

   Pulumi~partialclaimed3/10

   Pulumi offers a self-managed 'DIY' state backend (own S3/Azure Blob/GCS bucket) and self-hosting option, which indirectly lets users control where their infrastructure state data lives and delete it at will, rather than relying on Pulumi Cloud retention. However, there is no explicit documentation of data retention policies, deletion guarantees, or controls specifically for AI-related data (e.g., MCP server or Neo interaction logs). Missing for 10: explicit retention/deletion policy documentation, AI-specific data handling disclosures, and any deletion API/workflow for Pulumi Cloud-stored data.

   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Pulumi supports two classes of state backend: **Pulumi Cloud**: a managed backend...**DIY backend**: a “Do It Yourself” backend that stores …”
   • [claimed-docs] “Backend options include Pulumi Cloud, an easy-to-use, secure, and reliable hosted application ... in addition to simple object storage in AW…”
   • [claimed-docs] “Self-hosting available”

   proof ↗⚑ flag

3. 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

   Pulumi—none0/10

   The evidence pack contains no mention of a telemetry/usage-tracking opt-out setting (e.g., an env var, CLI flag, or config option) for Pulumi CLI or MCP server; no documentation or community evidence addresses telemetry controls at all.

   ⚑ flag

Ai authoring

1. ai-native userGenerate infrastructure code from natural language using AI assistance built into the toolchain

   weight 2 · round to Pulumi
   Terraform~partialprobed6/10

   Terraform ships an official MCP server that gives AI models real-time access to provider docs, modules, and policies specifically to enable 'more accurate and actionable Terraform configuration generation,' which supports natural-language-to-IaC workflows — but this is an integration layer for external AI assistants/agents rather than a natural-language generation feature built directly into the Terraform CLI/toolchain itself. missing for 10: no evidence of a native in-CLI NL-to-HCL generation feature, no independent/hands-on validation of the MCP server's generation quality, and no confirmation that generation is embedded rather than delegated to third-party AI tools.

   • [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] “official MCP server documented at https://developer.hashicorp.com/terraform/mcp-server”

   proof ↗⚑ flag

   Pulumi✓fullprobed8/10

   Pulumi ships a first-party MCP server explicitly documented to let AI assistants 'generate infrastructure code' from Pulumi Cloud context, and Pulumi Neo lets users 'tell Neo what you need in plain English' to provision infrastructure — both built into the toolchain. A hands-on probe confirms the MCP server actually runs and responds to JSON-RPC handshakes, corroborating the vendor claim beyond just documentation. Missing for 10: independent/hands-on evidence of actual natural-language-to-IaC code generation quality (only the handshake, not code-gen output, was tested) and no third-party corroboration of Neo's real-world behavior.

   • [claimed-docs] “The Pulumi Model Context Protocol (MCP) server enables AI-powered coding assistants to access your Pulumi Cloud resources, generate infrastr…”
   • [claimed-docs] “Tell Neo what you need in plain English. It handles dependencies, executes changes, and monitors outcomes automatically.”
   • [claimed-docs] “Neo provisions, governs, and optimizes your cloud infrastructure — with enterprise controls built in.”
   • [claimed-docs] “The Pulumi MCP server works with various AI-powered development tools: **Cursor**...**Anthropic’s Claude Code**...**Windsurf**...**Claude De…”
   • [probe] “PROBE mcp-handshake (local run): the official Pulumi MCP server (`npx @pulumi/mcp-server@latest stdio`, v0.2.0) answered a JSON-RPC initiali…”
   • [probe] “official MCP server documented at https://www.pulumi.com/docs/ai/mcp-server/”

   proof ↗⚑ flag

Languages

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

   weight 2 · round to Pulumi
   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

   Pulumi✓fullcommunity9/10

   Pulumi's core value proposition is defining infrastructure in general-purpose languages (TypeScript, Python, Go, .NET, Java) with full access to language features like loops, functions, classes, and types, backed by standard IDE tooling via SDKs; this is corroborated by community testimonials praising the type system and language ergonomics. Missing for 10: no direct evidence of specific IDE plugin/autocomplete features beyond inferred SDK typing benefits, and some community complaints about complexity/documentation temper a perfect score.

   • [claimed-docs] “Pulumi supports TypeScript, JavaScript, Python, Go, .NET, Java, YAML, and HCL. Each language is equally capable and supports the full surfac…”
   • [claimed-docs] “Define and manage cloud infrastructure using TypeScript, Python, Go, .NET, Java, and YAML.”
   • [github] “Skip the YAML, and use standard language features like loops, functions, classes, and package management that you already know and love.”
   • [community] “I love Pulumi. It's a joy to use a proper programming language to manage infra. I wish more tools would adapt this.”
   • [community] “I'm in love with Pulumi. Simply one of the best tools I have in my stack. After about a year of use, I simply cannot go back to editing YAML…”
   • [community] “Using Pulumi for about 1 year to manage gcp and AWS environments (5+) - each deployment is around 500 resources. At the begining it was bugg…”

   proof ↗⚑ 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

   Pulumi~partialprobed6/10

   Pulumi has a well-documented public Registry of providers/packages (referenced implicitly via 'Pulumi Registry providers' in pulumi-docs-1 and the MCP server description 'querying Pulumi Registry information' in pulumi-probe-8), and 300+ providers are consumable per pulumi-gh-2. However, the evidence pack lacks explicit documentation of a publishing workflow for developers to submit/publish their own reusable components/packages to the public Registry, versioning/discovery mechanics, or community corroboration of publishing experience. missing for 10: first-party docs on the publish/submission process for community packages, evidence of component/package authoring guides, independent/hands-on confirmation of publishing a package to the Registry.

   • [claimed-docs] “Pulumi supports TypeScript, JavaScript, Python, Go, .NET, Java, YAML, and HCL. Each language is equally capable and supports the full surfac…”
   • [github] “Pulumi automatically provisions and manages your resources on AWS, Azure, Google Cloud Platform, Kubernetes, and 300+ providers”
   • [probe] “PROBE mcp-handshake (local run): the official Pulumi MCP server (`npx @pulumi/mcp-server@latest stdio`, v0.2.0) answered a JSON-RPC initiali…”

   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

   Pulumi✓fullprobed9/10

   Pulumi's provider ecosystem is well documented with 300+ providers spanning AWS, Azure, GCP, Kubernetes, and SaaS offerings via the Pulumi Registry, corroborated by GitHub docs and confirmed hands-on via CLI probes deploying resources. Community evidence corroborates real-world multi-cloud usage (AWS, GCP, Azure, DigitalOcean) though some note documentation/provider lag issues for niche services. Missing for 10: independent quantification of SaaS-provider breadth beyond major clouds and no dispute-level evidence of provider gaps preventing broad usage.

   • [github] “Pulumi automatically provisions and manages your resources on AWS, Azure, Google Cloud Platform, Kubernetes, and 300+ providers”
   • [claimed-docs] “Pulumi supports TypeScript, JavaScript, Python, Go, .NET, Java, YAML, and HCL.”
   • [community] “Using Pulumi for about 1 year to manage gcp and AWS environments (5+) - each deployment is around 500 resources. At the begining it was bugg…”
   • [community] “We've now got the same stack structure going with Pulumi and Digital Ocean, having the same ease of development with at least 60% cost reduc…”
   • [community] “We switched to Pulumi from terraform for a new project because we can use it for both cloud infrastructure and for k8s configuration.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”

   proof ↗⚑ flag

Config stacks

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

   weight 2 · round to Pulumi
   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

   Pulumi✓fullprobed7/10

   Pulumi's core primitive of "stacks" is confirmed hands-on (pulumi stack init dev, pulumi preview/up/destroy per stack) and state/config is backend-scoped per stack (pulumi-docs-4/14/23, pulumi-probe-6/7), which is exactly the mechanism developers use to separate dev/staging/prod environments. Missing for 10: explicit documentation citation showing pulumi config set per-stack values and a documented dev→staging→prod promotion workflow, and no independent community confirmation specifically about multi-stack environment management.

   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”
   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Pulumi supports two classes of state backend: **Pulumi Cloud**: a managed backend...**DIY backend**: a “Do It Yourself” backend that stores …”
   • [claimed-docs] “Backend options include Pulumi Cloud, an easy-to-use, secure, and reliable hosted application ... in addition to simple object storage in AW…”

   proof ↗⚑ flag

Secrets

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

   weight 3 · round to Pulumi
   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

   Pulumi~partialprobed5/10

   A hands-on probe confirms Pulumi encrypts stack secrets via PULUMI_CONFIG_PASSPHRASE and can run headlessly with encrypted state (pulumi-probe-7), which supports the ability to store sensitive config outside code. However, the evidence pack lacks first-party docs on the `pulumi config set --secret` workflow, secret providers (KMS/Vault), or log redaction behavior, and there is no independent confirmation of masking-in-CLI-output claims. Missing for 10: docs on secret config commands and secret providers, evidence of automatic log/output redaction, and independent (non-vendor) verification of secrets never leaking in logs.

   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”
   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Pulumi supports two classes of state backend: **Pulumi Cloud**: a managed backend...**DIY backend**: a “Do It Yourself” backend that stores …”
   • [claimed-docs] “Backend options include Pulumi Cloud, an easy-to-use, secure, and reliable hosted application ... in addition to simple object storage in AW…”

   proof ↗⚑ flag

Drift

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

   weight 3 · round to Terraform
   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

   Pulumi~partialprobed6/10

   Pulumi's `pulumi preview` command computes a diff between declared program state and actual live resources, and this was verified hands-on (JSON steps output) without requiring cloud backend. State-and-backends docs also confirm Pulumi tracks resource state to compare against real infrastructure. However, the evidence never explicitly documents a dedicated `pulumi refresh` command or scheduled/automated drift-detection workflows (e.g. CI drift alerts), which are the more complete drift-detection story. missing for 10: explicit refresh command docs, automated/scheduled drift detection, independent community confirmation of drift-detection accuracy.

   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”

   proof ↗⚑ flag

State backends

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

   weight 3 · round to Pulumi
   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

   Pulumi✓fullcommunity8/10

   Pulumi docs explicitly describe remote backends (Pulumi Cloud managed service, and DIY backends like S3/Azure Blob/GCS) for storing state, and Pulumi Cloud/state services are designed to provide locking to prevent concurrent-run corruption; community evidence corroborates Pulumi's own state service option. missing for 10: explicit documentation/citation of locking mechanics for DIY object-store backends and independent third-party verification of lock behavior under concurrent runs.

   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Pulumi supports two classes of state backend: **Pulumi Cloud**: a managed backend...**DIY backend**: a “Do It Yourself” backend that stores …”
   • [claimed-docs] “Backend options include Pulumi Cloud, an easy-to-use, secure, and reliable hosted application ... in addition to simple object storage in AW…”
   • [community] “Pulumi maintains its own state service (with option of self management)... As a developer, I quite liked Pulumi resource model, documentatio…”

   proof ↗⚑ flag

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

   weight 2 · round to Pulumi
   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

   Pulumi✓fullprobed7/10

   Pulumi documents encrypted state backends and hands-on probe evidence confirms secrets are encrypted using PULUMI_CONFIG_PASSPHRASE even on a local file backend, verifying secret values are not stored in plaintext. Missing for 10: explicit documentation of KMS/cloud secrets-provider options for encrypting the whole state, independent third-party verification of encryption strength, and clarity on whether non-secret resource properties are also encrypted at rest.

   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”
   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Pulumi supports two classes of state backend: **Pulumi Cloud**: a managed backend...**DIY backend**: a “Do It Yourself” backend that stores …”
   • [claimed-docs] “Backend options include Pulumi Cloud, an easy-to-use, secure, and reliable hosted application ... in addition to simple object storage in AW…”

   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

   Pulumi~partialclaimed5/10

   Pulumi's docs show related state-safety capabilities — `pulumi import`/adoption for bringing existing resources under management (pulumi-docs-6,17,25), and `pulumi preview` for safely previewing changes without applying them (pulumi-docs-8,19,21) — plus general state backend concepts (pulumi-docs-4,14,23). However, the evidence pack never cites the actual `pulumi state mv`, `pulumi state rename`, or `pulumi state delete` commands that platform engineers use specifically for refactoring (moving/renaming/removing resources in state), so the core of the story is only indirectly supported. missing for 10: explicit documentation/evidence of `pulumi state move`, `pulumi state rename`, and `pulumi state delete` commands, plus hands-on confirmation these work safely during refactors.

   • [claimed-docs] “Adopting the existing resource to bring it under management by Pulumi... is called adoption or import.”
   • [claimed-docs] “Most infrastructure as code projects require working with existing cloud resources, whether those resources were originally created with ano…”
   • [claimed-docs] “you run `pulumi import` against a specific cloud resource. Pulumi adds the resource to your stack’s state and generates the code needed to m…”
   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”
   • [claimed-docs] “run `pulumi preview --import-file` to generate an import file listing every resource the program would otherwise create”
   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Pulumi supports two classes of state backend: **Pulumi Cloud**: a managed backend...**DIY backend**: a “Do It Yourself” backend that stores …”

   proof ↗⚑ flag

Testing

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

   weight 2 · round drawn
   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

   Pulumi✓fullprobed8/10

   Pulumi documents a dedicated testing framework with Unit Tests (mocked, no real cloud calls), Property Tests, and Integration Tests using standard language test frameworks, plus 'pulumi preview' to check changes without touching production and Automation API for programmatic test orchestration. This directly satisfies writing/running infra tests without touching production. Missing for 10: independent hands-on validation of the testing framework specifically (probes verify preview/up/destroy but not the unit-test mocking flow) and community commentary on test-writing experience.

   • [claimed-docs] “Unit Tests are fast in-memory tests that mock all external calls. Property Tests run resource-level assertions while infrastructure is being…”
   • [claimed-docs] “Unit Tests are fast in-memory tests that mock all external calls.”
   • [claimed-docs] “Unit tests are authored in the same language as the Pulumi program under test. You can use your favorite test and mock frameworks like Mocha…”
   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”
   • [claimed-docs] “The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”

   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

   Pulumi—none0/10

   No evidence of a dedicated 'pulumi validate' or 'pulumi fmt' style command that checks/auto-formats configuration prior to planning; Pulumi's docs only show 'pulumi preview' as a plan-preview step, and formatting is left to standard language tooling since Pulumi programs are written in general-purpose languages. missing for 10: no documented config validation command, no auto-formatting feature, no evidence of pre-plan syntax/config linting distinct from preview.

   ⚑ flag