Pulumi vs Crossplane

Agent access

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

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

   Crossplane—none0/10

   No evidence of an llms.txt file, agent-oriented documentation format, or any mention of AI-agent-consumable docs; docs-16 mentions AI systems acting on APIs but does not describe agent-oriented documentation discovery. missing for 10: llms.txt file or equivalent, agent-facing documentation format, any explicit reference to AI agents consuming docs directly.

   ⚑ flag

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

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

   Crossplane~partialprobed6/10

   Crossplane is fundamentally a Kubernetes control-plane operator: everything is driven by declarative YAML/CRDs reconciled by controllers, which is inherently automatable via kubectl/GitOps pipelines (ArgoCD/Flux) as community evidence confirms, and the CLI itself is keyless and scriptable. However the probe shows every real operation requires a live Kubernetes cluster with Crossplane installed — there's no standalone local plan/apply loop like other CLI-first tools, meaning 'headless CI' usage requires provisioning/maintaining a cluster as a CI dependency rather than a lightweight headless binary. missing for 10: evidence of a documented CI-specific workflow/example (e.g. official GitHub Action or CI recipe), confirmation of non-interactive apply without cluster bootstrap overhead, and independent hands-on reports of running Crossplane in CI pipelines.

   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”
   • [probe] “official CLI documented at https://docs.crossplane.io/cli/latest/”
   • [claimed-docs] “testing and rendering standalone Composition Functions without the need to access a Kubernetes cluster running Crossplane”
   • [community] “Many folks are using GitOps with Flux/ArgoCD to deploy their k8s apps but they can't use Terraform in the same workflow. How does Crossplane…”
   • [community] “Terraform offers small teams a common language for controlling their infrastructure...Crossplane appears to have a clear yaml syntax (easy e…”
   • [claimed-docs] “If your software ever drifts from your desired state, the control plane automatically corrects the drift.”

   proof ↗⚑ flag

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

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

   Crossplane—none0/10

   Crossplane is a Kubernetes control-plane framework, not an AI agent, so publishing an official MCP server is a plausible ecosystem capability, but no evidence in the pack mentions an MCP server, MCP integration, or agent connectivity of any kind—only marketing language about 'AI systems' acting on APIs, which is not an MCP server claim.

   • [claimed-docs] “Expose declarative APIs that humans, automation, and AI systems can safely act on”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

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

   Crossplane~partialprobed6/10

   Crossplane ships an official CLI (docs and hands-on probe confirm install via brew and working `crossplane version --client`) supporting building/testing/rendering Compositions and managing packages, but it is not framed or evidenced as an AI-native/agentic interface (no MCP integration, no agent-friendly output modes, no natural-language or automation-specific tooling beyond generic CLI usage). missing for 10: explicit AI-native design/marketing for the CLI itself, evidence of agent-friendly structured output or automation hooks, and independent corroboration beyond one hands-on probe.

   • [claimed-docs] “testing and rendering standalone Composition Functions without the need to access a Kubernetes cluster running Crossplane”
   • [claimed-docs] “troubleshooting Crossplane Compositions, Composite Resources and Managed Resources”
   • [claimed-docs] “building, installing, updating and pushing Crossplane Packages”
   • [probe] “official CLI documented at https://docs.crossplane.io/cli/latest/”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”

   proof ↗⚑ flag

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

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

   Crossplane✓fullprobed7/10

   Crossplane explicitly documents that it exposes 'declarative APIs that humans, automation, and AI systems can safely act on' (docs-16), and its architecture is built on the Kubernetes API server extended via CRDs/Managed Resources (docs-3, docs-13, docs-20, docs-21), which forms a standard, machine-readable, documented API surface. This is reinforced by an official CLI (probe-1, probe-2) for interacting with the control plane programmatically. missing for 10: independent/hands-on evidence of an AI agent actually driving Crossplane via the API, and more detail on API schemas/authentication for agentic use beyond marketing copy.

   • [claimed-docs] “Expose declarative APIs that humans, automation, and AI systems can safely act on”
   • [claimed-docs] “It lets you design the APIs and abstractions that your users use to interact with your control planes.”
   • [claimed-docs] “there’s an RDS instance MR that extends Kubernetes with the ability to manage AWS RDS instances.”
   • [claimed-docs] “Composite Resource Definitions - Define schemas for composite resources”
   • [probe] “official CLI documented at https://docs.crossplane.io/cli/latest/”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”

   proof ↗⚑ flag

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

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

   Crossplane~partialclaimed4/10

   Crossplane's own marketing claims it exposes 'declarative APIs that humans, automation, and AI systems can safely act on' and leverages Kubernetes RBAC for security, which implies a path to scoped, least-privilege access control for agentic consumers. However, there is no concrete documentation of an agent-specific credential-issuance mechanism (e.g., token minting, scoped API keys, or short-lived credentials tailored for AI agents) — it relies on generic Kubernetes RBAC rather than a purpose-built agent credentialing feature. Missing for 10: explicit agent-credential issuance workflow, scoping granularity examples, and independent verification that RBAC is actually used this way in practice.

   • [claimed-docs] “Expose declarative APIs that humans, automation, and AI systems can safely act on”
   • [claimed-docs] “extending its battle hardened reliability and security features like Role Based Access Control (RBAC) to orchestrate everything - not just c…”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

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

   Crossplane—none0/10

   Evidence describes Crossplane's function pipeline supporting multiple languages (YAML, KCL, Python, Go) and declarative APIs that 'AI systems can safely act on,' but there is no mention of an official SDK (e.g., function-sdk-go/python) or any AI-native developer tooling for building against Crossplane programmatically.

   ⚑ flag

8. ai-native userSubscribe to events via webhooks

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

   Crossplane—none0/10

   No evidence anywhere in the pack of an event/webhook subscription mechanism for AI agents or other consumers; Crossplane's model is Kubernetes-native reconciliation/drift-correction, not webhook-based event push. This is a fair capability to ask of an infrastructure control plane, but nothing in the evidence documents it.

   ⚑ flag

Agentic features

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

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

   Crossplane—none0/10

   Evidence only shows marketing language about exposing APIs that 'AI systems can safely act on' (crossplane-docs-16), which is about external agents calling Crossplane's API, not the product itself generating AI-driven insights or suggestions from data. No feature, dashboard, or docs describe AI-generated analysis, recommendations, or insights surfaced to users.

   • [claimed-docs] “Expose declarative APIs that humans, automation, and AI systems can safely act on”

   proof ↗⚑ flag

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

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

   Crossplane~partialclaimed5/10

   Crossplane's control plane continuously reconciles desired state and self-corrects drift autonomously (crossplane-docs-18), and its declarative APIs are explicitly framed as actionable by automation/AI systems (crossplane-docs-16), which supports background autonomous operation of infrastructure. However, there is no evidence of AI-native 'automations' or agentic workflows being set up specifically for AI systems, scheduled/triggered agent tasks, or any AI-specific orchestration features beyond generic drift-correction and declarative reconciliation. missing for 10: explicit AI-agent-triggered automation examples, scheduling/triggers for autonomous AI tasks, evidence of AI systems actually driving Crossplane resources end-to-end, independent hands-on validation of autonomous background operation.

   • [claimed-docs] “If your software ever drifts from your desired state, the control plane automatically corrects the drift.”
   • [claimed-docs] “Expose declarative APIs that humans, automation, and AI systems can safely act on”
   • [claimed-docs] “extending its battle hardened reliability and security features like Role Based Access Control (RBAC) to orchestrate everything - not just c…”

   proof ↗⚑ flag

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

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

   Crossplane—none0/10

   Crossplane's interface is entirely declarative YAML/Compositions plus a CLI for build/test/push workflows; the closest hit is marketing copy saying APIs can be 'acted on' by AI systems, but that describes external consumers, not natural-language command input into Crossplane itself. No documentation, CLI feature, or probe shows any natural-language command interface. Missing for 10: any NL command parser, chat/agent interface, or evidence of accepting free-text instructions instead of declarative manifests.

   • [claimed-docs] “Expose declarative APIs that humans, automation, and AI systems can safely act on”
   • [claimed-docs] “With Crossplane you don’t have to write a controller. Instead you configure a pipeline of functions.”
   • [probe] “official CLI documented at https://docs.crossplane.io/cli/latest/”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”

   proof ↗⚑ flag

Api quality

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

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

   Crossplane—none0/10

   No evidence of an interactive API reference with runnable examples exists in the pack; documentation is described only as static pages and CLI docs, with no mention of a live/interactive reference or embedded runnable code snippets.

   ⚑ flag

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

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

   Crossplane—none0/10

   Crossplane's CRD-based schemas (crossplane-docs-13) imply an OpenAPI-compatible structure inherent to Kubernetes, but the evidence pack contains no explicit documentation or feature describing a downloadable OpenAPI or machine-readable API spec for Crossplane's Composite Resources or Providers. Missing for 10: explicit docs on exporting/downloading OpenAPI schema, CLI or API endpoint for spec retrieval, and any community/hands-on confirmation of this capability.

   • [claimed-docs] “Composite Resource Definitions - Define schemas for composite resources”

   proof ↗⚑ flag

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

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

   Crossplane~partialprobed4/10

   Crossplane's CLI supports rendering/testing Composition Functions locally without needing a live Kubernetes cluster (crossplane-docs-7), which enables some local, production-safe testing. However, a probe shows that real plan/apply operations still require a running Kubernetes cluster with Crossplane installed, with no built-in local sandbox/preview loop for full resource provisioning — so isolating test workloads from production relies on the user provisioning a separate cluster/cloud account rather than a first-class sandbox feature. missing for 10: dedicated sandbox-mode or dry-run against real cloud providers, evidence of safe multi-tenant test isolation, and confirmation that render-only testing covers full MR/Composition behavior rather than just function outputs.

   • [claimed-docs] “testing and rendering standalone Composition Functions without the need to access a Kubernetes cluster running Crossplane”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”

   proof ↗⚑ flag

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

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

   Crossplane—none0/10

   While Crossplane exposes CRD-based APIs and has a 'Composition Revisions' feature for managing changes, the evidence pack contains no documentation of a formal API versioning scheme or deprecation policy for its own APIs (e.g., CRD version graduation, deprecation timelines, migration guides). Missing for 10: explicit deprecation policy docs, CRD version stability guarantees, migration/upgrade guidance for deprecated APIs.

   ⚑ flag

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

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

   Crossplane—none0/10

   The evidence describes Crossplane's declarative APIs, Compositions, and controller-based reconciliation, but nothing in the pack documents or demonstrates bulk/batch operations across many resources at once (e.g., batch apply, multi-resource templating at scale, or AI-driven bulk actions).

   ⚑ flag

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

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

   Crossplane~partialclaimed6/10

   Crossplane's control-plane model is inherently reactive: it continuously watches Kubernetes resource state and automatically corrects drift, and its composition function pipelines process changes to composite resources as they occur, which functions as an implicit event-driven automation model. However, there is no evidence of an explicit rule-authoring interface (e.g., 'on event X do Y' triggers, webhooks, custom event sources) — the automation is confined to declarative reconciliation loops built into the resource model. Missing for 10: explicit event-trigger/rule definition mechanism beyond drift reconciliation, documentation of custom event sources or conditional trigger logic, and independent confirmation of this automation depth.

   • [claimed-docs] “If your software ever drifts from your desired state, the control plane automatically corrects the drift.”
   • [claimed-docs] “With Crossplane you don’t have to write a controller. Instead you configure a pipeline of functions.”
   • [claimed-docs] “There’s already a Crossplane managed resource for that.”
   • [claimed-docs] “Functions - Functions extend Crossplane with new ways to configure composition”

   proof ↗⚑ flag

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

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

   Crossplane~partialcommunity6/10

   Crossplane's Composition Revisions explicitly let you manage and track changes to Compositions, and its YAML-based Kubernetes resources are naturally committed to source control and managed via GitOps, as community members note ('clear yaml syntax... easy enough to commit to source control'). Drift correction also provides a form of automatic rollback to desired state. missing for 10: explicit documentation of a review/approval workflow (e.g., PR-gated promotion), and a clear step-by-step rollback procedure using Composition Revisions rather than just their existence.

   • [claimed-docs] “Composition Revisions - Manage changes to Compositions with revisions”
   • [claimed-docs] “If your software ever drifts from your desired state, the control plane automatically corrects the drift.”
   • [community] “Terraform offers small teams a common language for controlling their infrastructure...Crossplane appears to have a clear yaml syntax (easy e…”
   • [community] “Many folks are using GitOps with Flux/ArgoCD to deploy their k8s apps but they can't use Terraform in the same workflow. How does Crossplane…”

   proof ↗⚑ flag

Import

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

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

   Crossplane—none0/10

   No evidence in the pack shows a Crossplane feature for importing existing/unmanaged cloud resources or auto-generating matching Composition/Claim YAML; the docs cover installation, packages, and compositions but nothing about resource discovery or import tooling. missing for 10: an import/adopt command or workflow, generated MR/Composition code from existing infra, any docs or community reports of migrating pre-existing resources into Crossplane management.

   ⚑ flag

Migration

1. platform-engineerMigrate an existing Terraform-format codebase and its state into this tool

   weight 2 · round to Pulumi
   Pulumi~partialclaimed6/10

   Pulumi documents importing existing (e.g., Terraform-created) resources via `pulumi import` and `pulumi preview --import-file`, generating Pulumi code and adding resources to Pulumi state, and explicitly markets migration from Terraform/CloudFormation. However, this is resource-by-resource adoption of live infrastructure, not a direct conversion of Terraform HCL codebase or import of Terraform state files themselves — no evidence of a bulk Terraform-state-to-Pulumi-state converter or HCL-to-native-language transpiler tool. missing for 10: evidence of direct Terraform state file import/conversion, bulk/automated HCL-to-Pulumi code conversion tooling, and independent/hands-on confirmation of a full codebase migration success story.

   • [claimed-docs] “Adopting the existing resource to bring it under management by Pulumi... is called adoption or import.”
   • [claimed-docs] “Migrate from Terraform, CloudFormation, and other tools.”
   • [claimed-docs] “Most infrastructure as code projects require working with existing cloud resources, whether those resources were originally created with ano…”
   • [claimed-docs] “run `pulumi preview --import-file` to generate an import file listing every resource the program would otherwise create”
   • [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

   Crossplane—none0/10

   No evidence of any Terraform-state import, HCL conversion, or migration tooling in Crossplane's docs, CLI, or community discussion; Crossplane uses an entirely different declarative Kubernetes-native model with no documented path to ingest existing Terraform codebases or state files.

   ⚑ 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 drawn
   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

   Crossplane—none0/10

   The evidence pack contains no mention of Crossplane's license (e.g., Apache 2.0) or its governance model (e.g., CNCF graduation, foundation stewardship) — nothing here addresses licensing-governance at all. missing for 10: license identification, governance/foundation structure, any statement on relicensing protection.

   ⚑ flag

Stability

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

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

   Crossplane—none0/10

   The evidence pack shows install/config docs, feature flags, and package management, but contains no explicit compatibility promises (e.g., API versioning policy) or dedicated upgrade/migration guides between Crossplane releases. This axis clearly applies to a platform like Crossplane, but no supporting evidence is present.

   ⚑ flag

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

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

   Crossplane✓fullclaimed7/10

   Crossplane is fundamentally a Kubernetes control-plane extension: all functionality (Providers, Compositions, Functions, Managed Resources) is exposed as declarative Kubernetes API objects (CRDs) manipulated via kubectl/API, with docs explicitly framing it as exposing 'declarative APIs that humans, automation, and AI systems can safely act on' and letting users 'design the APIs and abstractions' for their control planes — there is no separate UI gating capability. Missing for 10: no evidence pack mention of any Crossplane-native UI/console to explicitly confirm parity claims, and no independent/hands-on corroboration of full UI-API equivalence.

   • [claimed-docs] “Expose declarative APIs that humans, automation, and AI systems can safely act on”
   • [claimed-docs] “It lets you design the APIs and abstractions that your users use to interact with your control planes.”
   • [claimed-docs] “Extend Kubernetes to manage any resource anywhere”
   • [claimed-docs] “Composite Resource Definitions - Define schemas for composite resources”
   • [claimed-docs] “Providers - Providers connect Crossplane to external APIs”

   proof ↗⚑ flag

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

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

   Crossplane~partialclaimed5/10

   Crossplane's resources (Compositions, Configurations, Managed Resources) are defined as plain YAML/KCL/etc. stored in Kubernetes, which is inherently portable and inspectable, and packages are designed to be portable across clusters (crossplane-docs-11, crossplane-docs-2). However there is no explicit documented 'export all data' feature or bulk-export/migration tool, and no evidence addressing exporting live state or leaving the platform cleanly. missing for 10: explicit data-export/backup tooling, documentation of exporting full state (not just config) in open formats, and any evidence of migration/exit workflow.

   • [claimed-docs] “Functions allow you to write your configuration in multiple languages, including YAML, KCL, Python, and Go.”
   • [claimed-docs] “Configurations - Portable packages of Crossplane resources”
   • [claimed-docs] “Composite Resource Definitions - Define schemas for composite resources”
   • [claimed-docs] “Composition Revisions - Manage changes to Compositions with revisions”

   proof ↗⚑ flag

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

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

   Crossplane—none0/10

   No evidence pack item mentions Crossplane's source code license, GitHub repository, or open-source licensing terms (e.g., Apache 2.0) — the pack covers only product docs, community discussion, and CLI probes. Missing for 10: license file/declaration, repository link, any statement about open-source status or license type.

   ⚑ flag

4. ai-native userSelf-host the core product

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

   Crossplane✓fullprobed9/10

   Crossplane is an open-source Kubernetes control-plane extension that users install and run themselves via Helm on their own cluster, with full control over feature flags, package installation, and versions (docs-4, docs-5, docs-6, docs-19, docs-22, docs-25). The probe confirms hands-on that the CLI and control plane operate entirely against a self-managed Kubernetes cluster with no forced SaaS dependency (probe-2). Missing for 10: no explicit vendor statement contrasting self-hosting vs. any managed offering, and no independent write-up specifically about self-hosting experience at scale.

   • [claimed-docs] “Install Crossplane using the Helm chart.”
   • [claimed-docs] “Enable support for real time compositions.”
   • [claimed-docs] “Enable automatic protection of Providers from deletion when they have active managed resources.”
   • [claimed-docs] “Crossplane introduces new features behind feature flags. By default alpha features are off.”
   • [claimed-docs] “Installing Crossplane enables the installation of Crossplane Provider, Function, and Configuration resources.”
   • [claimed-docs] “Install pre-release versions of Crossplane from the master Crossplane Helm channel.”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”

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

   Crossplane—none0/10

   Crossplane's model is continuous reconciliation (drift correction) rather than a discrete plan/apply workflow, and the probe evidence explicitly states no local plan/preview loop exists — every operation requires a live cluster. There is no documented JSON plan output or diff artifact an agent could parse.

   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”
   • [claimed-docs] “If your software ever drifts from your desired state, the control plane automatically corrects the drift.”

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

   Crossplane~partialprobed4/10

   Crossplane's CLI supports rendering/testing Compositions standalone (crossplane-docs-7) which could let an agent preview a change, but the probe explicitly found no headless local plan/preview loop — every real plan/apply requires a live Kubernetes cluster with Crossplane installed (crossplane-probe-2), unlike Terraform-style plan/diff tools. There's no documented diff-and-approve workflow tailored for agent-authored changes. missing for 10: a genuine headless 'plan' command producing a diff against live state, documented agent/approval integration, evidence of an AI agent actually driving this workflow end-to-end.

   • [claimed-docs] “testing and rendering standalone Composition Functions without the need to access a Kubernetes cluster running Crossplane”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”
   • [claimed-docs] “Expose declarative APIs that humans, automation, and AI systems can safely act on”

   proof ↗⚑ flag

Automation api

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

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

   Crossplane~partialprobed5/10

   Crossplane exposes Kubernetes-native declarative APIs and explicitly markets itself as something 'humans, automation, and AI systems can safely act on', implying resources can be created/managed programmatically (e.g., via the Kubernetes API) rather than only via CLI. However, the evidence pack never documents an SDK, client library, or concrete example of driving Crossplane from application code — it only shows CLI tooling and YAML-based composition, and the probe confirms all real plan/apply operations require a running cluster with no programmatic preview path shown. missing for 10: explicit SDK/client-library documentation, a hands-on example of application code creating/managing Crossplane resources, and confirmation that this workflow is idiomatic (not just theoretically possible via raw Kubernetes API).

   • [claimed-docs] “Expose declarative APIs that humans, automation, and AI systems can safely act on”
   • [claimed-docs] “It lets you design the APIs and abstractions that your users use to interact with your control planes.”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”
   • [claimed-docs] “Installing Crossplane enables the installation of Crossplane Provider, Function, and Configuration resources.”

   proof ↗⚑ flag

Plan workflow

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

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

   Crossplane—none0/10

   The evidence pack never documents a destroy/teardown operation or workflow for Crossplane; it covers install, packages, functions, and drift-correction, but the only deletion-related item (crossplane-docs-6) is about *protecting* providers from deletion, not enabling clean teardown. No CLI or docs evidence shows a 'crossplane destroy' or cascading delete guarantee for an environment. Missing for 10: any documentation of a destroy/delete command, cascading resource cleanup behavior, or a described teardown workflow.

   • [claimed-docs] “Enable automatic protection of Providers from deletion when they have active managed resources.”
   • [claimed-docs] “building, installing, updating and pushing Crossplane Packages”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”

   proof ↗⚑ flag

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

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

   Crossplane—none0/10

   Crossplane operates as a continuously-reconciling Kubernetes control plane rather than a plan/apply tool with saved plan artifacts and approval gates; the evidence pack contains no documentation of a CI-oriented plan/apply/approve workflow. The hands-on probe explicitly notes that unlike Terraform-style tools, 'every real plan/apply operation requires a running Kubernetes cluster... no local plan/preview loop exists,' confirming the absence of this capability.

   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”
   • [claimed-docs] “testing and rendering standalone Composition Functions without the need to access a Kubernetes cluster running Crossplane”

   proof ↗⚑ flag

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

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

   Crossplane—none0/10

   Crossplane operates on a continuous-reconciliation model rather than an explicit plan/apply diff workflow; the CLI's `render` command only tests Composition Function output offline, and probe evidence explicitly states no local plan/preview loop exists — every real change requires a live cluster with the control plane reconciling live, not previewing creates/updates/destroys beforehand. missing for 10: any documented `crossplane plan`/diff command showing pending creates/updates/deletes, first-party guidance on previewing resource changes before applying, and independent confirmation of such a preview workflow.

   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”
   • [claimed-docs] “testing and rendering standalone Composition Functions without the need to access a Kubernetes cluster running Crossplane”
   • [claimed-docs] “If your software ever drifts from your desired state, the control plane automatically corrects the drift.”

   proof ↗⚑ flag

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

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

   Crossplane—none0/10

   Crossplane's docs describe compositions, functions, and CLI rendering/troubleshooting, but nothing in the evidence shows a mechanism to target or exclude specific resources during a plan/apply-like operation; the probe explicitly notes there is no local plan/preview loop at all, only continuous reconciliation via a running cluster. missing for 10: any documented `--target`/`--exclude` style flag or resource-selection mechanism for plan or apply operations.

   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”
   • [claimed-docs] “testing and rendering standalone Composition Functions without the need to access a Kubernetes cluster running Crossplane”
   • [claimed-docs] “troubleshooting Crossplane Compositions, Composite Resources and Managed Resources”

   proof ↗⚑ flag

Ai infra ops

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

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

   Crossplane~partialcommunity4/10

   Crossplane's RBAC-based control plane and 'developer only given permission to perform operations at the interface' model (comm-8, docs-17) support a least-privilege foundation, and its declarative API design is explicitly pitched as safe for AI systems to act on (docs-16), but there is no documented mechanism for agent-specific credential scoping, plan/approval review gates, or blocking unapproved applies before they take effect. missing for 10: explicit approval/review-gate workflow for AI-driven changes, agent-scoped least-privilege credential issuance, evidence of a 'plan preview' step analogous to Terraform plan, and independent validation that unauthorized changes are actually blocked.

   • [claimed-docs] “Expose declarative APIs that humans, automation, and AI systems can safely act on”
   • [claimed-docs] “extending its battle hardened reliability and security features like Role Based Access Control (RBAC) to orchestrate everything - not just c…”
   • [community] “Terraform (and cloud provider APIs) are not built for developer self-service...Crossplane flips this model by instead saying that the develo…”

   proof ↗⚑ flag

Policy

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

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

   Crossplane—none0/10

   The evidence pack describes Crossplane's control-plane architecture, RBAC, packages, and CLI tooling, but contains no mention of a policy-as-code engine (e.g., OPA/Gatekeeper/Kyverno integration, admission webhooks, or built-in policy checks) that blocks non-compliant infrastructure changes before apply. RBAC is referenced only as an access-control feature, not as a compliance gate.

   ⚑ flag

Ai authoring

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

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

   Crossplane—none0/10

   Evidence shows Crossplane exposes declarative APIs that AI systems could act on, but there is no documented feature for generating infrastructure code from natural language within the Crossplane toolchain itself (CLI, docs, or otherwise).

   ⚑ flag

Languages

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

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

   Crossplane~partialclaimed4/10

   Crossplane's core resource model (Compositions, XRDs) is YAML/CRD-based, but its Functions pipeline explicitly supports writing composition logic in general-purpose languages like Python and Go (as well as KCL), which brings type systems and IDE tooling into play (crossplane-docs-2, crossplane-docs-26). However, this applies only to the Function extension mechanism, not to defining the full infrastructure spec itself, and there's no evidence of dedicated SDKs, typed client libraries, or IDE integration for this workflow. missing for 10: dedicated general-purpose-language SDK for defining infra resources (not just functions), documented IDE/autocomplete support, type-safety examples, loop/programmatic composition examples, independent hands-on validation of this workflow.

   • [claimed-docs] “Functions allow you to write your configuration in multiple languages, including YAML, KCL, Python, and Go.”
   • [claimed-docs] “Functions - Functions extend Crossplane with new ways to configure composition”
   • [claimed-docs] “With Crossplane you don’t have to write a controller. Instead you configure a pipeline of functions.”

   proof ↗⚑ flag

Modules

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

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

   Crossplane~partialclaimed6/10

   Crossplane docs describe Providers and Configurations as portable, installable packages and the CLI supports building, installing, updating and pushing Crossplane Packages, plus a 'library of components to assemble your platform faster' — all indicating a publish/consume workflow for reusable modules. However, there is no explicit evidence of a named public registry (e.g., Upbound Marketplace) or details on registry discovery/versioning workflows. Missing for 10: explicit public registry reference/marketplace evidence, developer-facing publish workflow walkthrough, independent confirmation of module reuse via registry.

   • [claimed-docs] “building, installing, updating and pushing Crossplane Packages”
   • [claimed-docs] “Providers - Providers connect Crossplane to external APIs”
   • [claimed-docs] “Configurations - Portable packages of Crossplane resources”
   • [claimed-docs] “Use a library of components to assemble your platform faster”
   • [claimed-docs] “Installing Crossplane enables the installation of Crossplane Provider, Function, and Configuration resources.”

   proof ↗⚑ flag

Providers

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

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

   Crossplane~partialcommunity6/10

   Docs confirm a package-based Provider model that connects Crossplane to external APIs (e.g. AWS RDS) and describes a 'library of components' to assemble a platform, and community discussion references AWS/GCP/Azure-style resources being managed this way, supporting a broad multi-cloud provider ecosystem claim. However, the evidence pack never enumerates specific major-cloud or SaaS provider packages (Azure, GCP, Datadog, etc.) beyond AWS RDS, nor cites a provider marketplace/registry size or independent confirmation of breadth. missing for 10: explicit list/marketplace evidence of major cloud providers (Azure, GCP) and SaaS providers, independent verification of ecosystem breadth beyond AWS example.

   • [claimed-docs] “there’s an RDS instance MR that extends Kubernetes with the ability to manage AWS RDS instances.”
   • [claimed-docs] “Providers - Providers connect Crossplane to external APIs”
   • [claimed-docs] “Use a library of components to assemble your platform faster”
   • [community] “When he asks for the DB, is he getting an RDS/CloudSQL/whatever or is it spinning up a DB on an EKS/GKE/whatever? I really don't like the la…”
   • [community] “So how is this different from AWS Operator? ... The AWS operator targets AWS resources. You can't take them, in a general sense, to minikube…”

   proof ↗⚑ flag

Config stacks

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

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

   Crossplane~partialclaimed3/10

   Crossplane has 'Environment Configs' (in-memory data stores for Compositions) and 'Configurations' as portable packages, which could be used to parameterize per-environment settings, but there is no documented workspace/stack concept analogous to Terraform workspaces for isolating dev/staging/prod as separate stacks. missing for 10: explicit dev/staging/prod workspace pattern, first-party guidance on structuring multiple environments, independent corroboration of this use case.

   • [claimed-docs] “Environment Configs - In-memory data stores for Compositions”
   • [claimed-docs] “Configurations - Portable packages of Crossplane resources”
   • [claimed-docs] “Composition Revisions - Manage changes to Compositions with revisions”

   proof ↗⚑ flag

Secrets

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

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

   Crossplane—none0/10

   Crossplane orchestrates infrastructure via Kubernetes and secret/credential handling (e.g., Provider credentials, Kubernetes Secrets) is a plausible axis for such a control plane, but the evidence pack contains no mention of secrets management, credential injection, or log redaction mechanisms. missing for 10: any documentation or community evidence of secret injection, secure credential storage, or protection from log exposure.

   ⚑ flag

Drift

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

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

   Crossplane✓fullcommunity8/10

   Crossplane's control-plane model continuously reconciles declared desired state against actual cloud resources and self-corrects drift automatically, as documented directly ('If your software ever drifts from your desired state, the control plane automatically corrects the drift'). This is reinforced by its reconciliation-based architecture (managed resources, compositions) rather than one-off plan/apply. Missing for 10: independent hands-on verification/benchmarks of drift-detection behavior in production, and no detail on drift visibility/reporting tooling (e.g., diffing UI) beyond auto-correction.

   • [claimed-docs] “If your software ever drifts from your desired state, the control plane automatically corrects the drift.”
   • [claimed-docs] “There’s already a Crossplane managed resource for that.”
   • [claimed-docs] “there’s an RDS instance MR that extends Kubernetes with the ability to manage AWS RDS instances.”
   • [community] “Terraform is a popular tool for provisioning infrastructure...Unlike Crossplane, Terraform does not support workload portability across clou…”

   proof ↗⚑ flag

State backends

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

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

   Crossplane—none0/10

   The evidence pack contains no mention of encryption at rest, state files, secrets handling, or etcd encryption for Crossplane's managed resource state. Crossplane stores its state as Kubernetes custom resources rather than flat state files, but no documentation here addresses how sensitive values are protected from plaintext exposure. missing for 10: any docs on etcd encryption, secret handling for provider credentials, or state-at-rest encryption guarantees.

   ⚑ flag

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

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

   Crossplane—none0/10

   The evidence pack shows Crossplane CLI features for troubleshooting and rendering Compositions/Managed Resources, but there is no documentation or community evidence of a safe state-inspection/modification workflow (e.g., moving, renaming, or removing resources from state) analogous to Terraform's state mv/rm/import commands. Refactoring-safety for live infrastructure state is a fair axis for any IaC/control-plane tool, so absence of evidence here yields 'none' rather than 'na'.

   • [claimed-docs] “troubleshooting Crossplane Compositions, Composite Resources and Managed Resources”
   • [probe] “official CLI documented at https://docs.crossplane.io/cli/latest/”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”

   proof ↗⚑ flag

Testing

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

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

   Crossplane!disputedcontradicted5/10

   Docs claim the Crossplane CLI supports 'testing and rendering standalone Composition Functions without the need to access a Kubernetes cluster running Crossplane' (crossplane-docs-7), which would let developers test infra code without touching production. However, a hands-on probe explicitly found that 'unlike other tools probed here every real plan/apply operation requires a running Kubernetes cluster with the Crossplane control plane installed — no local plan/preview loop exists' (crossplane-probe-2), directly contradicting the claim of a self-contained local testing workflow. Missing for 10: independent confirmation that `crossplane render` works fully offline for realistic compositions, CI/CD test-suite examples, and reconciliation of the docs/probe discrepancy.

   • [claimed-docs] “testing and rendering standalone Composition Functions without the need to access a Kubernetes cluster running Crossplane”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”

   proof ↗⚑ flag

2. developerValidate and auto-format my configuration before planning

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

   Crossplane~partialprobed3/10

   The Crossplane CLI supports offline testing/rendering of Compositions without a cluster (crossplane-docs-7, crossplane-docs-8), which partially covers 'validate,' but there is no evidence of an auto-format command, and crossplane-probe-2 explicitly notes there is no local plan/preview loop — every real operation requires a live cluster, unlike a typical validate→format→plan workflow. missing for 10: dedicated auto-format tooling, an actual 'plan' equivalent step, and independent confirmation of the validate/render workflow's completeness.

   • [claimed-docs] “testing and rendering standalone Composition Functions without the need to access a Kubernetes cluster running Crossplane”
   • [claimed-docs] “troubleshooting Crossplane Compositions, Composite Resources and Managed Resources”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”

   proof ↗⚑ flag