Skip to content

Rename Insights Discovery / Insights Accounts terminology to Discovery / Cloud Accounts - #20528

Open
CamSoper wants to merge 1 commit into
masterfrom
claude/repo-wide-implementation-plan-m6lu4g
Open

Rename Insights Discovery / Insights Accounts terminology to Discovery / Cloud Accounts#20528
CamSoper wants to merge 1 commit into
masterfrom
claude/repo-wide-implementation-plan-m6lu4g

Conversation

@CamSoper

Copy link
Copy Markdown
Contributor

Proposed changes

Implements the naming decision from this Slack thread (Tatiana, signed off by Dylan, Cam, and Alex): start using the language we want to land at for the Discovery feature, ahead of the broader naming cleanup.

Renames applied (44 files, terminology and labels only):

  • "Pulumi Insights Discovery" / "Insights Discovery" → "Discovery"
  • "Insights account(s)" → "cloud account(s)" (docs prose, titles/H1s, RBAC pages, tutorial)
  • "Insights & Governance" → "Discovery & Governance" — docs left-nav (data/docs_menu_sections.yml, flows to /llms.txt and /docs/llm-sitemap.json), header nav, footer, docs landing card, homepage, pricing, and /product/insights-governance/ page copy
  • Discovery-subtree title_tags rebranded from ... | Pulumi Insights to ... | Discovery & Governance, and "Pulumi Insights:" H1 prefixes dropped, matching the pattern the Policies subtree already uses

Deliberately unchanged (so reviewers can veto scope choices cheaply):

  • No URL, filename, directory, menu-key, or alias changes/docs/insights/... paths stay; the section-directory rename belongs to the future broader cleanup, so no redirects are needed here
  • API/RBAC scope identifiers (insights_account:*, insights_scan) — product API strings
  • content/docs/iac/cli/commands/* — auto-generated from pulumi/pulumi; the ~42 "Insights account" mentions there (and the pulumi insights account command itself) need an upstream change
  • assets/openapi/tag-intros/insights-accounts.md (tied to the OpenAPI tag name), standalone "Pulumi Insights" brand mentions (glossary term, schema.org entities, pricing SKU copy), blog posts, events, releases, and customer quotes (the Modivcare quote in what-is-policy-as-code keeps its original wording)

Small adjacent fixes made while renaming:

  • Two links pointed at the legacy /docs/insights/accounts/ alias instead of the canonical /docs/insights/discovery/accounts/ (visual-import, policy-groups)
  • The AWS/Azure/GCP integration pages labeled a link to the accounts page as "Insights discovery overview"; now labeled "Discovery overview" and pointed at the actual overview page
  • Wrong image alt text (Insights Account Discovery Scan) on two Resource Explorer screenshots

Verification: lint-markdown passes (0 errors, 1828 files), Prettier clean on all changed files, full Hugo production build succeeds with 0 errors, and rendered output spot-checked: left nav / llms.txt / llm-sitemap show "Discovery & Governance", the accounts page renders "Create and Manage Cloud Accounts", homepage/pricing/product pages show the new label with zero stale occurrences. git diff --name-status confirms zero renames.

Unreleased product version (optional)

N/A

Related issues (optional)

Naming decision: Slack thread in #C0737NLJCJ3


Generated by Claude Code

Adopt the agreed naming for the Discovery feature ahead of the broader
naming cleanup:

- "Pulumi Insights Discovery" / "Insights Discovery" -> "Discovery"
- "Insights account(s)" -> "cloud account(s)"
- "Insights & Governance" section label -> "Discovery & Governance"
  (docs nav, header/footer nav, homepage, pricing, product page)

Terminology and labels only: no URLs, filenames, menu keys, or aliases
change. API scope identifiers (insights_account:*), the auto-generated
CLI docs, the OpenAPI tag intro, blog history, and standalone "Pulumi
Insights" brand mentions are intentionally left as-is.

Also fixes a few adjacent issues surfaced while renaming: two links
that pointed at the legacy /docs/insights/accounts/ alias, the
mislabeled "Insights discovery overview" links on the cloud
integration pages, and wrong image alt text on the Resource Explorer
get-started page.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KhVcxmBo96dQZH7fnDgq1f
@pulumi-bot

Copy link
Copy Markdown
Collaborator

Your site preview for commit 3b54cfa is ready! 🎉

http://www-testing-pulumi-docs-origin-pr-20528-3b54cfae.s3-website.us-west-2.amazonaws.com

Changed pages:

@pulumi-bot

Copy link
Copy Markdown
Collaborator

Lighthouse Performance Report

Commit: 3b54cfa | Metric definitions

Page Device Score FCP LCP TBT CLS SI
Homepage Mobile 🔴 41 3.0s 4.6s 2532ms 0.072 7.5s
Homepage Desktop 🟡 74 0.8s 1.6s 321ms 0.036 2.8s
Install Pulumi Mobile 🟡 59 6.2s 8.8s 68ms 0.053 6.2s
Install Pulumi Desktop 🟡 78 1.4s 2.1s 0ms 0.015 3.1s
AWS Get Started Mobile 🔴 48 6.0s 9.6s 64ms 0.235 6.0s
AWS Get Started Desktop 🟡 78 1.4s 2.2s 0ms 0.019 3.1s

@CamSoper
CamSoper marked this pull request as ready for review July 27, 2026 23:58
@github-actions github-actions Bot added review:triaging Claude Triage is currently classifying the PR domain:website PR touches marketing, pricing, legal, or competitive landing pages domain:docs PR touches technical docs domain:mixed PR touches more than one domain domain:infra PR touches workflows, scripts, infra, Makefile, or build config review:in-progress Claude review is currently running and removed review:triaging Claude Triage is currently classifying the PR labels Jul 27, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Pre-merge Review — Last updated 2026-07-28T00:03:04Z

Tip

Summary: This is a repository-wide terminology rename across docs, marketing, nav, and data files (+180/-180 over 44 files): "Insights Discovery" → "Discovery", "Insights Accounts" → "Cloud Accounts", and the "Insights & Governance" section label → "Discovery & Governance". Every edit is prose, frontmatter, or nav-label text — no code, no structural moves. The kind of wrongness that would hurt a reader here is an incomplete rename (some references updated while siblings keep the old term) or an internal link broken by the change; the review therefore leaned on cross-sibling consistency and link/frontmatter checks. External claim verification (215 claims), a cross-sibling read of the RBAC-scopes and insights directories, a frontmatter/alias sweep, and style linting all ran. Note: many claims were flagged "contradicted" purely because the verification step compared the PR's new wording against the still-live production pages, which haven't been updated yet — the expected signal for a not-yet-merged rename, not a defect. After triage, nothing in this PR blocks merge; the only substantive findings (a possibly-broken REST-API link and two alias collisions) are pre-existing on lines this PR doesn't touch.

Review confidence:

Dimension Level Notes
mechanics HIGH
facts MEDIUM Contradiction flags all trace to the verifier comparing new wording against not-yet-updated live pages; each was triaged as expected for a rename, and no genuine factual error survived.
cross-sibling consistency HIGH Rename applied consistently across the RBAC-scopes and insights siblings; scope literals (insights_account:*) and the page identifier/alias are intentionally retained.
Investigation log
  • Cross-sibling reads: 5 of 5 siblings (RBAC-scopes and insights directories; terminology consistent)
  • External claim verification: 194 of 213 claims verified (4 unverifiable, 8 contradicted) · 4 specialists (numerical, cross-reference, capability, framing); 0 cross-specialist corroborations · routed: 0 inline, 202 Pass 1, 1 Pass 2 (verified 0, contradicted 0, unverifiable 1), 10 Pass 3 (verified 4, contradicted 5, unverifiable 1).
  • Cited-claim spot-checks: 1 of 1 cited claims fetched and compared
  • Frontmatter sweep: ran on body + meta_desc
  • Temporal-trigger sweep: ran (recency words present in diff; spot-check in-review)
  • Code execution: not run (no static/programs/ change)
  • Code-examples checks: not run (no fenced code blocks in content files)
  • Editorial-balance pass: not run (not under content/blog/)
🚨 Outstanding ⚠️ Low-confidence 💡 Pre-existing ✅ Resolved
0 19 3 0

🔍 Verification trail

215 claims extracted · 194 verified · 4 unverifiable · 8 contradicted
  • L33 in content/docs/administration/access-identity/rbac/_index.md "In Pulumi Cloud, a team can be granted access two ways: through roles and through entity access granted directly on specific stacks, environments, and cloud ac…" → ✅ verified (evidence: The claim quotes verbatim from the source file itself (rbac/_index.md L33), and the linked teams page confirms the two mechanisms: "teams can be assigned roles (default or custom). This is separate from Team entity access grants (stack-lev…; source: repo:content/docs/administration/access-identity/rbac/_index.md and repo:content/docs/administration/access-identity/rbac/teams.md)
  • L61 in content/docs/administration/access-identity/rbac/_index.md "In Pulumi Cloud, teams can be granted entity access directly on specific stacks, environments, and cloud accounts, outside of any role, and team members receiv…" → ✅ verified (evidence: Sibling page teams.md states: "Teams can be granted direct access to stacks, environments, and cloud accounts. All team members receive access to those entities at the selected permission level," under the "Team Entity Access Grants" secti…; source: repo:content/docs/administration/access-identity/rbac/teams.md)
  • L73 in content/docs/administration/access-identity/rbac/_index.md "In Pulumi Cloud RBAC, entities are the Pulumi Cloud objects that permission sets are granted on, comprising stacks, environments, and cloud accounts, plus orga…" → ✅ verified (evidence: Line 73 of the same doc states: "Entities and organization-level access: The Pulumi Cloud objects that permission sets are granted on — stacks, environments, and cloud accounts — plus the organization-level access that governs org-wide ope…; source: repo:content/docs/administration/access-identity/rbac/_index.md)
  • L3 in content/docs/administration/access-identity/rbac/entities.md "Entities in Pulumi Cloud RBAC include stacks, environments, and cloud accounts, which are the objects that permission sets are granted on, alongside organizati…" → ✅ verified (evidence: The doc states "Pulumi Cloud has three entity types: Stacks..., Environments..., Cloud accounts..." and separately covers "Organization-level access" as not an entity type but governed by org access level — matching the claim exactly.; source: repo:content/docs/administration/access-identity/rbac/entities.md)
  • L30 in content/docs/administration/access-identity/rbac/entities.md "The full list of stack scopes is documented at /docs/administration/access-identity/rbac/scopes/stacks." → ✅ verified (evidence: The page at content/docs/administration/access-identity/rbac/scopes/stacks.md exists and lists the full set of stack scopes (Stacks, Stack Deployments, Stack Deploy Schedules, Stack Tags, Stack Webhooks tables), consistent with the cross-r…; source: repo:content/docs/administration/access-identity/rbac/scopes/stacks.md)
  • L30-31 in content/docs/administration/access-identity/rbac/entities.md "Stack-related operations governed by RBAC include updates, configuration, deployment settings, tags and annotations, webhooks, and schedules." → ✅ verified (evidence: The doc itself states: "Stacks: All operations that affect stacks — updates, configuration, deployment settings, tags and annotations, webhooks, and schedules." This matches the claim exactly.; source: repo:content/docs/administration/access-identity/rbac/entities.md)
  • L31-32 in content/docs/administration/access-identity/rbac/entities.md "Cloud accounts in Pulumi Cloud RBAC cover all operations that affect cloud accounts, including accounts, policy evaluations, scan configurations, and results a…" → 🤝 matches (evidence: entities.md line 32 states verbatim: "Cloud accounts: All operations that affect cloud accounts — accounts, policy evaluations, scan configurations, and results and reports." This is consistent with the sibling scope…; source: repo:content/docs/administration/access-identity/rbac/entities.md and repo:content/docs/administration/access-identity/rbac/scopes/insights-accounts.md)
  • L36 in content/docs/administration/access-identity/rbac/entities.md "Organization-level operations are not an entity type and are not tied to individual objects, so they are not granted through entity access rules." → ✅ verified (evidence: The doc states verbatim: "Organization-level operations — billing, member management, audit logs, integrations, and other organization settings — are not an entity type. They aren't tied to individual objects, so you don't grant them t…; source: repo:content/docs/administration/access-identity/rbac/entities.md)
  • L36 in content/docs/administration/access-identity/rbac/entities.md "Configuration of organization access is documented at /docs/administration/access-identity/rbac/roles#custom-roles." → ✅ verified (evidence: The target page content/docs/administration/access-identity/rbac/roles.md has a "## Custom roles" section (anchor #custom-roles) which explains: "Organization access sets the permission level for organization-level operations (e.g. cre…; source: repo:content/docs/administration/access-identity/rbac/roles.md)
  • L36 in content/docs/administration/access-identity/rbac/entities.md "Organization-level operations in Pulumi Cloud include billing, member management, audit logs, integrations, and other organization settings." → ✅ verified (evidence: The source file states verbatim: "Organization-level operations — billing, member management, audit logs, integrations, and other organization settings — are not an entity type." This exactly matches the claim's list of organization-le…; source: repo:content/docs/administration/access-identity/rbac/entities.md)
  • L38 in content/docs/administration/access-identity/rbac/entities.md "Meta-permissions are organization-level actions that can't be attached to an existing entity because the entity doesn't exist yet, since there's no specific st…" → ✅ verified (evidence: Doc text at L38 reads: "Organization-level access also covers meta-permissions: actions that can't be attached to an existing entity because the entity doesn't exist yet. Creating a stack (stack:create), a team (team:create), or a cloud ac…; source: repo:content/docs/administration/access-identity/rbac/entities.md)
  • L41 in content/docs/administration/access-identity/rbac/entities.md "Organization-level scopes such as stack:create and team:create are granted through a role's organization access level." → ✅ verified (evidence: The same file states: "Creating a stack (stack:create), a team (team:create)... is governed at the organization level rather than per-entity" and the info box explicitly says "Organization-level scopes (e.g. stack:create, `team:creat…; source: repo:content/docs/administration/access-identity/rbac/entities.md (L38, L41); repo:content/docs/administration/access-identity/rbac/roles.md)
  • L41 in content/docs/administration/access-identity/rbac/entities.md "Organization-level scopes are separate from the capability toggles in Organization-wide role settings, documented at /docs/administration/access-identity/rbac/…" → 🤝 matches (evidence: entities.md states: "Organization-level scopes (e.g. stack:create, team:create) are granted through a role's organization access level. These are separate from the capability toggles in Organization-wide role settings... which apply to mem…; source: repo:content/docs/administration/access-identity/rbac/entities.md and repo:content/docs/administration/access-identity/rbac/roles.md)
  • L41 in content/docs/administration/access-identity/rbac/entities.md "The 'Allow organization members to create stacks' capability toggle applies to members on the Member role." → ✅ verified (evidence: roles.md states: "Allow organization members to create stacks and transfer stacks to this organization — When enabled, members on the Member role can create new stacks..." and the section intro confirms these toggles "apply only to members…; source: repo:content/docs/administration/access-identity/rbac/roles.md)
  • L17 in content/docs/administration/access-identity/rbac/permission-sets.md "Permission sets in Pulumi Cloud provide a way to grant related access rights to an entity (resource) or set of entities (resources)." → ✅ verified (evidence: The doc itself states: "They provide a convenient way to grant related access rights to an entity (resource) or set of entities (resources)." The claim is a direct paraphrase of this in…; source: repo:content/docs/administration/access-identity/rbac/permission-sets.md)
  • L19 in content/docs/administration/access-identity/rbac/permission-sets.md "Every permission set in Pulumi Cloud belongs to a specific entity type (stacks, environments, or cloud accounts) and can only include scopes of that same type." → ✅ verified (evidence: entities.md's "Entity types" section (anchor #entity-types) states: "When creating a permission set, it must be of a specific entity type, and can only include scopes of that same type." and lists the three entity types as Stacks, Environm…; source: repo:content/docs/administration/access-identity/rbac/entities.md)
  • L43-44 in content/docs/administration/access-identity/rbac/permission-sets.md "The Environment Write permission set includes the Environment Open scopes plus environment:write, environment:rotate, environment_version:create, envi…" → ✅ verified (evidence: The table row in the same file reads: "Environment Write| Ability to modify environment settings. | Environment Open, +environment:write, environment:rotate, environment_version:create, environment_version:update, environment_…; source: repo:content/docs/administration/access-identity/rbac/permission-sets.md)
  • L46 in content/docs/administration/access-identity/rbac/permission-sets.md "Pulumi Cloud has a category of permission sets called 'Cloud account permission sets' (renamed from 'Insights account permission sets')." → ✅ verified (evidence: The permission-sets.md page uses "Cloud account permission sets" as the current section heading (L46), while the underlying scopes retain the legacy insights_account:* naming and the sibling scopes page has identifier `pulumi-cloud-acces…; source: repo:content/docs/administration/access-identity/rbac/scopes/insights-accounts.md, repo:content/docs/administration/access-identity/rbac/entities.md)
  • L50-52 in content/docs/administration/access-identity/rbac/permission-sets.md "The Account Write permission set provides the ability to modify cloud accounts, includes everything in Account Read, plus the scopes insights_account:upda…" → ✅ verified (evidence: Table row in the same doc: "Account Write| Ability to modify cloud accounts. | Account Read, +insights_account:update, insights_account:scan, insights_account_scan:update, insights_account_scan:cancel, insights_account_scan:pa…; source: repo:content/docs/administration/access-identity/rbac/permission-sets.md)
  • L60-61 in content/docs/administration/access-identity/rbac/permission-sets.md "The Read Only organization permission set includes exactly these scopes: ai_conversations:read, deployments:read, deployments:read_usage, environment:…" → ✅ verified (evidence: The exact Read Only scope list in the claim matches the current content of content/docs/administration/access-identity/rbac/permission-sets.md verbatim (ai_conversations:read, deployments:read, deployments:read_usage, environment:list_d…; source: gh search code --owner pulumi "ai_conversations:read" / "environment:list_deleted"; repo:pulumi/pulumi-pulumiservice provider/pkg/apitype/rbac_permission_.go)
  • L85 in content/docs/administration/access-identity/rbac/permission-sets.md "The 'Entities and organization-level access' guide covers organization-level access that governs org-wide operations, and is located at /docs/administration/ac…" → ✅ verified (evidence: The linked page content/docs/administration/access-identity/rbac/entities.md exists at that path, titled "Entities and Organization Level Access", and states: "Organization-level operations — billing, member management, audit logs, integra…; source: repo:content/docs/administration/access-identity/rbac/entities.md)
  • L88 in content/docs/administration/access-identity/rbac/roles.md "The Account permissions dropdown sets the access level that members on the Member role have to all cloud accounts, linked from /docs/insights/." → ✅ verified (evidence: Source doc reads: "The Account permissions dropdown sets the access level that members on the Member role have to all cloud accounts" — exact match to the claim text and link target.; source: repo:content/docs/administration/access-identity/rbac/roles.md)
  • L90-91 in content/docs/administration/access-identity/rbac/roles.md "In the Account permissions dropdown, the None option means members have no default access to accounts, and the Read option means members can view accounts, the…" → 🤝 matches (evidence: The doc text at L90-91 reads verbatim: "None — Members have no default access to accounts." and "Read — Members can view accounts, their scan configurations, and scan results." This mirrors the exact structure/wording pattern used…; source: repo:content/docs/administration/access-identity/rbac/roles.md)
  • L97 in content/docs/administration/access-identity/rbac/roles.md "When the 'Allow organization members to create accounts' toggle is disabled, only members whose role includes the insights_account:create scope can create new…" → ✅ verified (evidence: roles.md L97 states: "Allow organization members to create accounts — When enabled, members on the Member role can create new cloud accounts. When disabled, only members whose role includes the insights_account:create scope can do so." T…; source: repo:content/docs/administration/access-identity/rbac/roles.md#L97)
  • L129 in content/docs/administration/access-identity/rbac/roles.md "To grant a direct rule, you choose the entity type, select 'Select specific [type]', then select 'Choose [type]' to open a searchable list." → ✅ verified (evidence: Line 129 of the same doc states: "Direct rules grant a permission set to individually selected entities. Choose the entity type (stack, environment, or cloud account), select Select specific [type], then select Choose [type] to ope…; source: repo:content/docs/administration/access-identity/rbac/roles.md)
  • L129 in content/docs/administration/access-identity/rbac/roles.md "To grant a direct rule, you select 'Select specific [type]', then select 'Choose [type]' to open a searchable list." → ✅ verified (evidence: Line 129 of the same file states: "Direct rules grant a permission set to individually selected entities. Choose the entity type (stack, environment, or cloud account), select Select specific [type], then select Choose [type] to op…; source: repo:content/docs/administration/access-identity/rbac/roles.md#L129)
  • L129 in content/docs/administration/access-identity/rbac/roles.md "Direct rules grant a permission set to individually selected entities, and the entity type can be chosen as stack, environment, or cloud account." → ✅ verified (evidence: Source text: "Direct rules grant a permission set to individually selected entities. Choose the entity type (stack, environment, or cloud account), select Select specific [type]..." which matches the claim exactly.; source: repo:content/docs/administration/access-identity/rbac/roles.md L129)
  • L131 in content/docs/administration/access-identity/rbac/roles.md "The dialog for selecting entities in a direct rule lists the entities in your organization and allows searching by name to filter the list." → ✅ verified (evidence: The doc itself states at L131: "A dialog lists the entities in your organization. You can search by name to filter the list." This matches the claim's description of the direct rule entity-selection dialog exactly.; source: repo:content/docs/administration/access-identity/rbac/roles.md)
  • L143-147 in content/docs/administration/access-identity/rbac/roles.md "Tag-based rules, also called ABAC (attribute-based access control), grant a permission set when a resource's tags match defined conditions, and each rule consi…" → 🤝 matches (evidence: The claim is a direct paraphrase of the file's own text: "Tag-based rules (also called ABAC — attribute-based access control) grant a permission set when a resource's tags match defined conditions. Each rule has: Entity type..., Tag condit…; source: repo:content/docs/administration/access-identity/rbac/roles.md L143-147)
  • L145 in content/docs/administration/access-identity/rbac/roles.md "For tag-based (ABAC) rules, the Entity type field can be Stack, environment, or cloud account." → 🤝 matches (evidence: The sibling page entities.md states "Pulumi Cloud has three entity types: Stacks, Environments (Pulumi ESC), Cloud accounts", and roles.md itself consistently lists "stack, environment, or cloud account" for direct/global entity access rul…; source: repo:content/docs/administration/access-identity/rbac/entities.md and repo:content/docs/administration/access-identity/rbac/roles.md)
  • L193 in content/docs/administration/access-identity/rbac/roles.md "Scopes are the most granular access rights in Pulumi Cloud, written as object:action, and each scope belongs to one entity type and is the building block of pe…" → 🤝 matches (evidence: scopes.md states: "Scopes are the most granular level of access control in Pulumi Cloud's RBAC system... Scopes follow a consistent naming pattern: object:action... Scopes are always associated with a specific entity type... Scopes are the…; source: repo:content/docs/administration/access-identity/rbac/scopes.md)
  • L193 in content/docs/administration/access-identity/rbac/roles.md "Each scope belongs to one entity type and is the building block of permission sets." → 🤝 matches (evidence: scopes.md states "Scopes are always associated with a specific entity type... and can only be used within permission sets that match that entity type" and "Scopes are the building blocks of permission sets" — directly confirming both parts…; source: repo:content/docs/administration/access-identity/rbac/scopes.md)
  • L194 in content/docs/administration/access-identity/rbac/roles.md "Permission sets are reusable bundles of related scopes for a single entity type." → ✅ verified (evidence: permission-sets.md states: "Permission sets in Pulumi Cloud are predefined bundles of scopes that are commonly used together... Every permission set belongs to a specific entity type... and can only include scopes of that same type." This…; source: repo:content/docs/administration/access-identity/rbac/permission-sets.md)
  • L194-196 in content/docs/administration/access-identity/rbac/roles.md "Entities and organization-level access are documented at /docs/administration/access-identity/rbac/entities, describing the objects that permission sets are gr…" → ✅ verified (evidence: The target page content/docs/administration/access-identity/rbac/entities.md exists and states: "Pulumi Cloud has three entity types: Stacks... Environments... Cloud accounts..." and a separate "Organization-level access" section covering…; source: repo:content/docs/administration/access-identity/rbac/entities.md)
  • L196 in content/docs/administration/access-identity/rbac/roles.md "Each member inherits the union of the team's roles on top of their own role." → 🤝 matches (evidence: teams.md states: "teams can also be assigned roles ... so that members receive the union of the team's roles and their own user role", which directly matches the roles.md summary line "Each member inherits the union of the team's roles on…; source: repo:content/docs/administration/access-identity/rbac/teams.md)
  • L196 in content/docs/administration/access-identity/rbac/roles.md "Teams are groups of users that can be assigned roles and entity access." → 🤝 matches (evidence: teams.md states: "Teams allow organization admins to assign a set of stack permissions to a group of users... teams can also be assigned roles... so that members receive the union of the team's roles and their own user role." This corrobor…; source: repo:content/docs/administration/access-identity/rbac/teams.md)
  • L31 in content/docs/administration/access-identity/rbac/scopes.md "Scopes are always associated with a specific entity type (like stacks, environments, cloud a…" → ✅ verified (evidence: entities.md contains a "## Entity types" heading (anchor #entity-types) listing Stacks, Environments, and Cloud accounts as the three entity types, and states "When creating a permission set, it must be of a specific entity type, and can o…; source: repo:content/docs/administration/access-identity/rbac/entities.md)
  • L60 in content/docs/administration/access-identity/rbac/scopes.md "- Entities and organization-level access: The objects that permission sets are granted on (stacks, enviro…" → ✅ verified (evidence: entities.md exists at the linked path and describes exactly this: entity types are Stacks, Environments, and Cloud accounts ("Pulumi Cloud has three entity types: Stacks... Environments... Cloud accounts...") plus an "Organization-level ac…; source: repo:content/docs/administration/access-identity/rbac/entities.md)
  • L2 in content/docs/administration/access-identity/rbac/scopes/insights-accounts.md "This RBAC scopes document is titled 'RBAC Scopes: Cloud Accounts' and covers 'Cloud accounts' scopes (renamed from 'Insights Accounts')." (also L4-5, L8) → ✅ verified (evidence: The file's frontmatter shows title: "RBAC Scopes: Cloud Accounts", h1: "RBAC Scopes: Cloud Accounts", menu name: "Cloud accounts", and body section "## Cloud accounts", with aliases redirecting from the old /scopes/insights-accounts path…; source: repo:content/docs/administration/access-identity/rbac/scopes/insights-accounts.md)
  • L4-5 in content/docs/administration/access-identity/rbac/scopes/insights-accounts.md "The page title and heading for this RBAC scopes page is 'RBAC Scopes: Cloud Accounts'." → ❌ contradicted (framing: shifted — the claim renames "Insights accounts" to "Cloud Accounts," referring to a different subject/entity type than the source page actually documents.; evidence: The live page at this URL is titled "Pulumi Cloud: RBAC Scopes - Insights accounts | Pulumi Docs", not "RBAC Scopes: Cloud Accounts". The page content also confirms it covers "insights accounts," not generic "Cloud Accounts."; source: https://www.pulumi.com/docs/administration/access-identity/rbac/scopes/insights-accounts/)
  • L8 in content/docs/administration/access-identity/rbac/scopes/insights-accounts.md "The navigation menu entry for this page is named 'Cloud accounts'." → ✅ verified (evidence: Front matter of the file shows: menu: administration: name: "Cloud accounts" — confirming the nav menu entry name matches the claim.; source: repo:content/docs/administration/access-identity/rbac/scopes/insights-accounts.md)
  • L11 in content/docs/administration/access-identity/rbac/scopes/insights-accounts.md "The RBAC scopes page identifier and legacy alias URL retain the term 'insights-accounts' even though the page content and headings have been renamed to 'cloud…" (also L15) → ✅ verified (evidence: Front matter shows identifier: pulumi-cloud-access-management-rbac-scopes-insights-accounts and aliases like /docs/pulumi-cloud/access-management/rbac/scopes/insights-accounts/, while title, h1, menu name: "Cloud accounts", and b…; source: repo:content/docs/administration/access-identity/rbac/scopes/insights-accounts.md)
  • L18 in content/docs/administration/access-identity/rbac/scopes/insights-accounts.md "This document defines all the available scopes in Pulumi Cloud that are assignable to specific cloud accounts or sets of cloud accounts." → ✅ verified (evidence: The file itself states verbatim: "This document defines all the available scopes in Pulumi Cloud assignable to specific cloud accounts or sets of cloud accounts," matching the claim text…; source: repo:content/docs/administration/access-identity/rbac/scopes/insights-accounts.md)
  • L21 in content/docs/administration/access-identity/rbac/scopes/insights-accounts.md "Pulumi Cloud's configurable RBAC features are only available in the Pulumi Enterprise or Business Critical editions." → ✅ verified (evidence: The pricing page's tier matrix lists "Role-based access control (RBAC)" with items _blank, _blank, _check, _check against tiers ordered Individual, Team, Enterprise, Business Critical — meaning RBAC is only included in Enterprise and Bus…; source: repo:content/pricing/_index.md (lines ~296-302, ~14-90))
  • L24 in content/docs/administration/access-identity/rbac/scopes/insights-accounts.md "Creating, listing, or restoring cloud accounts are organization-level operations, and the scopes for these operations can be found in the organization settings…" → ✅ verified (evidence: The org-settings scopes page linked (/docs/administration/access-identity/rbac/scopes/org-settings) does have a "Cloud accounts" section with insights_account:create listed as an org-level (role-based, not account-scoped) scope, confirmi…; source: repo:content/docs/administration/access-identity/rbac/scopes/org-settings.md)
  • L30-34 in content/docs/administration/access-identity/rbac/scopes/insights-accounts.md "The insights_account:update scope allows modifying cloud account settings and configurations, including updating monitoring parameters and analysis rules, an…" → ✅ verified (evidence: The doc table states: "insights_account:update | Modify cloud account settings and configurations. This allows updating monitoring parameters and analysis rules.

    Granted by default permission set: Account Write" — matching t…; source: repo:content/docs/administration/access-identity/rbac/scopes/insights-accounts.md)
  • L30-34 in content/docs/administration/access-identity/rbac/scopes/insights-accounts.md "The scope names in the tables (e.g. insights_account_access:read, insights_account:delete, insights_account:scan) retain the literal string 'insights_acc…" (also L40-45) → ✅ verified (evidence: File content confirms: table rows show insights_account_access:read, insights_account:delete, insights_account:scan, etc. as literal scope Value strings, while Description column and prose (title "Cloud Accounts", "This document defi…; source: repo:content/docs/administration/access-identity/rbac/scopes/insights-accounts.md)
  • L40-45 in content/docs/administration/access-identity/rbac/scopes/insights-accounts.md "The insights_account:scan scope initiates a new scan of a cloud account, triggering analysis of infrastructure configurations and compliance, and is granted…" → ✅ verified (evidence: Table row states: "insights_account:scan | Initiate a new scan of a cloud account. This triggers analysis of infrastructure configurations and compliance.

    Granted by default permission set: Account Write" — matches the claim…; source: repo:content/docs/administration/access-identity/rbac/scopes/insights-accounts.md)
  • L84 in content/docs/administration/access-identity/rbac/scopes/org-settings.md "| insights_account:create | Create a new cloud account. This allows setting up monitoring and analysis capabilities for infrastructure.

    **Granted by d…" → ⚔️ mismatch (evidence: The scope insights_account:create exists in pulumi-pulumiservice's rbac_permission_.go, but the current docs repo consistently describes it as creating an "insights account" (e.g. content/docs/administration/access-identity/rbac/scopes/o…; source: gh search code --owner pulumi "insights_account:create")
  • L98 in content/docs/administration/access-identity/rbac/scopes/org-settings.md "| policy_results:create | Create policy evaluation results for a cloud account.

    Granted by default roles: Admin |" → 🤷 unverifiable (evidence: Search results confirm the org-settings RBAC scopes page exists and covers organization-level operations including policy evaluations/insights accounts, but the specific table row for policy_results:create and its default-role grant to `…; source: WebSearch ran query "Pulumi RBAC scopes policy_results:create"; top results didn't show the specific scope table row)
  • L153 in content/docs/administration/access-identity/rbac/teams.md "- Entities and organization-level access: The objects that permission sets are granted on (stacks, enviro…" → ✅ verified (evidence: The linked page content/docs/administration/access-identity/rbac/entities.md exists at the exact path cited, and describes exactly the three entity types "Stacks", "Environments (Pulumi ESC)", "Cloud accounts" that permission sets are gran…; source: repo:content/docs/administration/access-identity/rbac/entities.md)
  • L72 in content/docs/administration/onboarding-guide/ways-of-working.md "Start by creating an organization—a container for your IaC projects and stacks, ESC projects and environments, and cloud accounts and discovered resources. Mos…" → ✅ verified (framing: shifted — minor wording variance: source says "Insights accounts and discovered resources" while claim says "cloud accounts and discovered resources"; substanc…; evidence: The live Pulumi docs page states: "Start by creating an organization—a container for your IaC projects and stacks, ESC projects and environments, and Insights accounts and discovered resources." and "Most companies need only a single organ…; source: https://www.pulumi.com/docs/administration/onboarding-guide/ways-of-working/)
  • L34 in content/docs/deployments/concepts/customer-managed-runners.md "Customer-Managed Workflow Runners support all the deployment triggers currently offered by Pulumi Deployments such as c…" → ✅ verified (evidence: The linked triggers page (content/docs/deployments/concepts/triggers.md) enumerates exactly these triggers: Push to deploy (git push), Click to Deploy, REST API, Scheduled operations/drift/TTL, Review stacks, and Deployment webhooks — matc…; source: repo:content/docs/deployments/concepts/triggers.md)
  • L64 in content/docs/deployments/guides/customer-managed-workflow-runners.md "You can designate one pool as the organization default. When a default pool is set, any deployment, Discovery scan, or policy evaluation that does not have…" → ✅ verified (evidence: The live page at the claim's own path states verbatim: "You can designate one pool as the organization default." and "When a default pool is set, any deployment, Insights discovery scan, or policy evaluation that does not have an explicit…; source: https://www.pulumi.com/docs/deployments/guides/customer-managed-workflow-runners/)
  • L2-3 in content/docs/insights/_index.md "The Pulumi product/feature area formerly named 'Insights & Governance' is now named 'Discovery & Governance'." (also L12) → ❌ contradicted (evidence: Live Pulumi docs and product pages (fetched May 2026) still use the name "Insights & Governance," not "Discovery & Governance." E.g. the docs page title is "Insights & Governance | Pulumi Docs" and breadcrumbs read "Insights & Governance ·…; source: https://www.pulumi.com/docs/insights/; intuition: No corroborating source anywhere uses "Discovery & Governance" as a product/section name; all current pages consistentl…)
  • L11 in content/docs/insights/_index.md "Pulumi Discovery & Governance provides comprehensive cloud visibility and policy enforcement, allowing users to discover cloud infrastructure and enforce polic…" → ✅ verified (evidence: The page's own frontmatter states: "Pulumi Discovery & Governance provides comprehensive cloud visibility and policy enforcement—discover all infrastructure and ensure compliance, regardless of how resources were created," and meta_desc: "…; source: repo:content/docs/insights/_index.md)
  • L14 in content/docs/insights/_index.md "Pulumi Discovery & Governance provides comprehensive cloud visibility and policy enforcement to discover all infrastructure and ensure compliance regardless of…" → 🤝 matches (evidence: The claim is a verbatim restatement of the page's own frontmatter description: "Pulumi Discovery & Governance provides comprehensive cloud visibility and policy enforcement—discover all infrastructure and ensure compliance, regardless of h…; source: repo:content/docs/insights/_index.md)
  • L14 in content/docs/insights/_index.md "Pulumi Discovery & Governance discovers all infrastructure and ensures compliance regardless of how resources were created." → ✅ verified (evidence: The page's own description field states: "Pulumi Discovery & Governance provides comprehensive cloud visibility and policy enforcement—discover all infrastructure and ensure compliance, regardless of how resources were created," which dire…; source: repo:content/docs/insights/_index.md)
  • L40-41 in content/docs/insights/_index.md "The Discovery feature scans cloud accounts and organizes resources for visibility and import." → ✅ verified (evidence: Line 41 of the same file states: "Learn how Discovery scans cloud accounts and organizes resources for visibility and import," and line 37 adds "Scan your cloud accounts and discover all infrastructure resources," directly supporting the c…; source: repo:content/docs/insights/_index.md)
  • L43 in content/docs/insights/_index.md "The navigation heading previously labeled 'Accounts' is now labeled 'Cloud Accounts', linking to /docs/insights/discovery/accounts/." → ✅ verified (evidence: content/docs/insights/_index.md currently shows the Discovery card block with heading: Cloud Accounts and link: /docs/insights/discovery/accounts/, exactly matching the claim. The target page content/docs/insights/discovery/accounts.md…; source: repo:content/docs/insights/_index.md and repo:content/docs/insights/discovery/accounts.md (fetched via gh_query))
  • L43-45 in content/docs/insights/_index.md "Cloud Accounts can be connected to sync and monitor infrastructure resources via a page at /docs/insights/discovery/accounts/." → ✅ verified (evidence: The page content/docs/insights/discovery/accounts.md exists and renders at /docs/insights/discovery/accounts/; sibling docs describe it as "Create and manage accounts" / "Insights accounts documentation" for connecting cloud accounts, matc…; source: gh api repos/pulumi/docs/contents/content/docs/insights/discovery (accounts.md present); gh search code showing links to /docs/insights/discovery/accounts/)
  • L86-89 in content/docs/insights/_index.md "Pulumi's Self-hosted Insights/Discovery feature allows running Discovery scans and policy evaluations in a customer's own environment using customer-managed wo…" → ✅ verified (evidence: Source text at L86-89: "Self-hosted Insights ... Run Discovery scans and policy evaluations in your own environment using customer-managed workflow runners." The claim is a direct paraphrase of this line.; source: repo:content/docs/insights/_index.md)
  • L88 in content/docs/insights/_index.md "The page at /docs/insights/self-hosted/ documents Self-hosted Insights functionality." → ✅ verified (evidence: content/docs/insights/self-hosted.md (which resolves to URL /docs/insights/self-hosted/) has title "Self-hosted Insights" and states: "Pulumi Insights supports self-hosted operation for Business Critical customers through customer-managed…; source: gh api repos/pulumi/docs/contents/content/docs/insights/self-hosted.md)
  • L4 in content/docs/insights/discovery/_index.md "Pulumi's Discovery feature enables organizations to gain complete visibility into their cloud infrastructure by scanning cloud provider accounts and building a…" (also L18) → ➖ not-a-claim (evidence: The claim text is a verbatim quote of the page's own introductory sentence in content/docs/insights/discovery/_index.md, describing the PR author's own product feature rather than a third-party attributed assertion.; source: repo:content/docs/insights/discovery/_index.md)
  • L18 in content/docs/insights/discovery/_index.md "Pulumi's Discovery feature enables organizations to gain complete visibility into their cloud infrastructure by scanning cloud provider accounts and building a…" → ✅ verified (evidence: The claim is a verbatim quote of the page's own text: "Pulumi's Discovery feature enables organizations to gain complete visibility into their cloud infrastructure by scanning cloud provider accounts and building a comprehensive inventory…; source: repo:content/docs/insights/discovery/_index.md)
  • L22 in content/docs/insights/discovery/_index.md "Discovery integrates with Pulumi ESC (Environments, Secrets, and Configuration) to securely manage credentials and scan cloud infrastructure." → ✅ verified (evidence: The doc itself states: "Discovery integrates with Pulumi ESC (Environments, Secrets, and Configuration) to securely manage credentials and scan your cloud infrastructure." The claim is a near-verbatim restatement of this line, and later te…; source: repo:content/docs/insights/discovery/_index.md)
  • L24 in content/docs/insights/discovery/_index.md "Users can create and configure cloud accounts through the Cloud Accounts page in Pulumi Cloud, where they can view scan status, monitor progress, and manage se…" → ✅ verified (evidence: The linked target page content/docs/insights/discovery/accounts.md describes exactly this: navigating to Management > Accounts to connect cloud accounts, viewing scan status ("see the child accounts ... for scan status"), and managing sett…; source: repo:content/docs/insights/discovery/accounts.md)
  • L26 in content/docs/insights/discovery/_index.md "Discovery authenticates to the cloud provider using credentials from ESC, then identifies resources, collects metadata, records relationships, and updates the…" → ✅ verified (evidence: The claim is a direct quote of the doc's own text: "Discovery authenticates to your cloud provider using credentials from ESC, then identifies resources, collects metadata, records relationships, and updates the Insights supergraph with th…; source: repo:content/docs/insights/discovery/_index.md)
  • L26 in content/docs/insights/discovery/_index.md "Discovery identifies resources, collects metadata, records relationships, and updates the Insights supergraph with the latest state during resource scanning." → 🤝 matches (evidence: The doc itself states: "Resource scanning: Discovery authenticates to your cloud provider using credentials from ESC, then identifies resources, collects metadata, records relationships, and updates the Insights supergraph with the latest…; source: repo:content/docs/insights/discovery/_index.md)
  • L77 in content/docs/insights/discovery/_index.md "There exists a 'Get started with Discovery' guide located at /docs/insights/discovery/get-started/." → ✅ verified (evidence: content/docs/insights/discovery/get-started/_index.md exists with title 'Get Started' / h1 'Get Started with Discovery', matching the linked path /docs/insights/discovery/get-started/.; source: repo:content/docs/insights/discovery/get-started/_index.md)
  • L81-85 in content/docs/insights/discovery/_index.md "There exists a guide titled 'Connect cloud accounts in bulk' located at /docs/insights/discovery/connect-cloud-accounts/." → ✅ verified (evidence: The file content/docs/insights/discovery/connect-cloud-accounts.md exists with title "Connect Cloud Accounts" and describes the bulk onboarding wizard ("onboards one or more cloud accounts to Pulumi in a single guided flow... supports bulk…; source: repo:content/docs/insights/discovery/connect-cloud-accounts.md)
  • L2-5 in content/docs/insights/discovery/accounts.md "This page describes how to create cloud accounts used by Discovery to scan provider resources for use within Pulumi Cloud." → ✅ verified (evidence: The claim text is a verbatim quote of the page's own meta_desc frontmatter: "meta_desc: This page describes how to create cloud accounts used by Discovery to scan provider resources for use within Pulumi Cloud." The page body confirms th…; source: repo:content/docs/insights/discovery/accounts.md)
  • L16 in content/docs/insights/discovery/accounts.md "This document outlines the steps required to create and manage a cloud account used to scan provider resources." → ➖ not-a-claim (evidence: This is the document's own introductory sentence describing its purpose ("This document outlines the steps required to create and manage a cloud account used to scan provider resources."), matching the page's actual content (account creati…; source: repo:content/docs/insights/discovery/accounts.md)
  • L18-19 in content/docs/insights/discovery/accounts.md "Pulumi provides a 'Connect cloud accounts wizard' at /docs/insights/discovery/connect-cloud-accounts/ for onboarding many AWS, Azure, or Google Cloud accounts…" → ✅ verified (evidence: accounts.md itself states: "To onboard many AWS, Azure, or Google Cloud accounts at once, use the Connect cloud accounts wizard." The linked page confirms: "The wizard supports bulk disco…; source: repo:content/docs/insights/discovery/accounts.md and repo:content/docs/insights/discovery/connect-cloud-accounts.md)
  • L18-19 in content/docs/insights/discovery/accounts.md "This document ('Create and Manage Cloud Accounts') covers connecting a single cloud account using a Pulumi ESC (Environments, Secrets, and Configuration) envir…" → ✅ verified (evidence: The doc's own info note states: "To onboard many AWS, Azure, or Google Cloud accounts at once, use the Connect cloud accounts wizard... This page covers connecting a single account using a Pulumi ESC (Environments, Secrets, and Configurati…; source: repo:content/docs/insights/discovery/accounts.md)
  • L30 in content/docs/insights/discovery/accounts.md "On the accounts page, selecting the Connect cloud accounts button opens the connection wizard." → ✅ verified (evidence: The doc's own "Account creation" steps state: "On this page, select the Connect cloud accounts button to open the connection wizard." This directly matches the claim.; source: repo:content/docs/insights/discovery/accounts.md)
  • L33 in content/docs/insights/discovery/accounts.md "Pulumi currently supports AWS, Azure, Google Cloud, Oracle Cloud, and Kubernetes as providers for cloud accounts." → ✅ verified (evidence: The doc itself states: "Currently, Pulumi supports AWS, Azure, Google Cloud, Oracle Cloud, and Kubernetes as providers for cloud accounts." — the claim is a verbatim restatement of this line in the same file (content/docs/insights/discover…; source: repo:content/docs/insights/discovery/accounts.md)
  • L35 in content/docs/insights/discovery/accounts.md "On the Authentication step, choosing 'Connect using existing ESC credentials' and selecting an ESC environment with the correct credentials allows Pulumi to va…" → ✅ verified (evidence: The doc itself states: "On the Authentication step, choose Connect using existing ESC credentials and select an ESC environment that has the correct credentials to scan the selected provider, then select Next. Pulumi validates the credenti…; source: repo:content/docs/insights/discovery/accounts.md)
  • L46 in content/docs/insights/discovery/accounts.md "When creating a new cloud account for AWS, a scan is kicked off immediately, and child accounts (one for each region) show scan status." → ✅ verified (evidence: The doc itself states: "A scan should be kicked off immediately. If you are creating a new cloud account for AWS, see the child accounts (one for each region) for scan status." This is the source content the claim is describing, so it matc…; source: repo:content/docs/insights/discovery/accounts.md (L46))
  • L51 in content/docs/insights/discovery/accounts.md "Currently, child accounts can only be created automatically by Pulumi, and this is only done in the case of AWS regions." → ✅ verified (evidence: The doc itself states: "Currently, child accounts can only be created automatically by Pulumi and is only done so in the case of AWS regions." This is consistent with the following section "How child accounts work," which says Pulumi creat…; source: repo:content/docs/insights/discovery/accounts.md)
  • L51 in content/docs/insights/discovery/accounts.md "Account hierarchies allow users to organize and manage cloud accounts in a structured way." → ✅ verified (evidence: The claim text is a direct restatement of the document's own content: "Account hierarchies allow you to organize and manage cloud accounts in a structured way." from the "Account hierarchies" section of accounts.md.; source: repo:content/docs/insights/discovery/accounts.md)
  • L51 in content/docs/insights/discovery/accounts.md "In the future, the account hierarchies feature will be expanded to support creating custom hierarchies, providing more flexibility for structuring accounts, su…" → 🤷 unverifiable (evidence: This is a forward-looking roadmap statement about Pulumi Insights' own product plans (self-contained in the same doc, consistent with the adjacent line noting Kubernetes cluster child-account support "will soon" be added). It's a first-par…; source: repo:content/docs/insights/discovery/accounts.md; intuition: Roadmap/future-feature claims in first-party docs are typically not falsifiable until shipped; treat as authorial inten…)
  • L60-63 in content/docs/insights/discovery/accounts.md "After deleting or excluding a child account like 'us-east-1', future scans of 'my-aws-account' will no longer include 'us-east-1' unless it is updated." → ✅ verified (evidence: The doc itself states: "you can still scan or delete my-aws-account/us-east-1 without affecting other children of my-aws-account and future scans of my-aws-account will no longer include us-east-1 unless it is updated" — the claim…; source: repo:content/docs/insights/discovery/accounts.md)
  • L101 in content/docs/insights/discovery/accounts.md "The user selects the AWS partition matching the account being scanned on the Discovery step when creating a cloud account." → ✅ verified (evidence: Line 101 states: "Select the partition that matches the account you are scanning on the Discovery step when you create the cloud account", consistent with line 39: "For AWS, also select the partition the account belongs to and the regions…; source: repo:content/docs/insights/discovery/accounts.md)
  • L101 in content/docs/insights/discovery/accounts.md "Pulumi Insights supports every AWS partition." → ✅ verified (evidence: The doc text itself enumerates all 8 known AWS partitions (Standard, GovCloud, ISO, ISOB, ISOF, ISOE, European Sovereign Cloud, China) immediately after the claim: "Pulumi Insights supports every AWS partition. Select the partition that ma…; source: repo:content/docs/insights/discovery/accounts.md (L99-111))
  • L103-104 in content/docs/insights/discovery/accounts.md "AWS Standard (commercial) and AWS GovCloud (US) are among the AWS partitions listed as supported." → ✅ verified (evidence: Pulumi blog confirms: "Pulumi Insights account scanning now supports every AWS partition," including GovCloud, and specifically states "Pulumi Insights now scans every AWS partition — GovCloud, ISO, European Sovereign, China — alongside St…; source: https://www.pulumi.com/blog/scan-aws-govcloud-china-with-pulumi-insights/)
  • L145-147 in content/docs/insights/discovery/accounts.md "An ESC environment can be configured to assume an AWS role via OIDC, as described in the ESC AWS provider documentation at /docs/esc/guides/configuring-oidc/aw…" → ✅ verified (evidence: The page at /docs/esc/guides/configuring-oidc/aws/ exists and states: "This document outlines the steps required to configure Pulumi to use OpenID Connect to authenticate with AWS. OIDC in AWS uses a web identity provider to assume an IAM…; source: repo:content/docs/esc/guides/configuring-oidc/aws.md)
  • L147 in content/docs/insights/discovery/accounts.md "To assign an ESC environment to a cloud account, the user links the ESC environment to the cloud account during account creation." → ✅ verified (evidence: Line 147 of the same file states: "4. Assign the ESC environment: Link the ESC environment to your cloud account during account creation." This directly matches the claim's text, and the workflow section (step 35) also describes select…; source: repo:content/docs/insights/discovery/accounts.md)
  • L211-214 in content/docs/insights/discovery/accounts.md "For Azure, once the ESC environment is set up with the proper credentials (either OIDC or client secret), it is assigned to the cloud account during the accoun…" → ✅ verified (evidence: The doc states verbatim: "Once the ESC environment is set up with the proper credentials (either OIDC or client secret), assign it to your cloud account during the account creation phase." This matches the claim's description exactly and i…; source: repo:content/docs/insights/discovery/accounts.md)
  • L239-242 in content/docs/insights/discovery/accounts.md "Once the ESC environment is set up with the proper credentials, it can be assigned to a cloud account during the account creation phase (for OCI)." → 🤝 matches (evidence: Line 242 of the same file states verbatim: "Once the ESC environment is set up with the proper credentials, assign it to your cloud account during the account creation phase." This is under the OCI section (line 216 "### OCI"), consistent…; source: repo:content/docs/insights/discovery/accounts.md)
  • L5 in content/docs/insights/discovery/connect-cloud-accounts.md "The Connect cloud accounts wizard onboards AWS, Azure, and Google Cloud accounts to Pulumi in bulk with OIDC authentication." → ✅ verified (evidence: The doc's meta description states: "Use the Connect cloud accounts wizard to onboard AWS, Azure, and Google Cloud accounts to Pulumi in bulk with OIDC authentication," and the body confirms "The wizard supports bulk discovery for AWS, Micr…; source: repo:content/docs/insights/discovery/connect-cloud-accounts.md)
  • L13 in content/docs/insights/discovery/connect-cloud-accounts.md "The Connect cloud accounts wizard sets up a Pulumi ESC (Environments, Secrets, and Configuration) environment for each discovered account." → ✅ verified (evidence: The page itself states the wizard "sets up everything each account needs: short-lived credentials based on OpenID Connect (OIDC), a Pulumi ESC (Environments, Secrets, and Configuration) environment, a scheduled discovery scan…; source: repo:content/docs/insights/discovery/connect-cloud-accounts.md)
  • L15 in content/docs/insights/discovery/connect-cloud-accounts.md "A page titled 'Create and manage cloud accounts' exists at /docs/insights/discovery/accounts/ describing how to connect Kubernetes and Oracle Cloud accounts or…" → ✅ verified (evidence: content/docs/insights/discovery/accounts.md has h1 "Create and Manage Cloud Accounts", resolves to /docs/insights/discovery/accounts/, and states "Currently, Pulumi supports AWS, Azure, Google Cloud, Oracle Cloud, and Kubernetes as provide…; source: repo:content/docs/insights/discovery/accounts.md)
  • L102 in content/docs/insights/discovery/connect-cloud-accounts.md "The account picker wizard shows how many accounts, subscriptions, or projects it discovered and pre-selects everything that isn't already connected." → ✅ verified (evidence: Line 102 of the source doc states verbatim: "The wizard shows how many accounts, subscriptions, or projects it discovered and pre-selects everything that isn't already connected." The claim is a direct restatement of this documented behavi…; source: repo:content/docs/insights/discovery/connect-cloud-accounts.md#L102)
  • L102 in content/docs/insights/discovery/connect-cloud-accounts.md "The wizard pre-selects everything that isn't already connected." → ✅ verified (evidence: Line 102 of the same doc states verbatim: "The wizard shows how many accounts, subscriptions, or projects it discovered and pre-selects everything that isn't already connected." The claim is a direct restatement of this documented behavior.; source: repo:content/docs/insights/discovery/connect-cloud-accounts.md)
  • L102 in content/docs/insights/discovery/connect-cloud-accounts.md "Selecting 'Edit selected accounts' opens a picker where you can search, select all, or toggle individual accounts." → ✅ verified (evidence: The doc itself states: "Select Edit selected accounts ... to open the picker, where you can search, select all, or toggle individual accounts," matching the claim exactly.; source: repo:content/docs/insights/discovery/connect-cloud-accounts.md#L102)
  • L102 in content/docs/insights/discovery/connect-cloud-accounts.md "Accounts that are already connected appear with an 'Already onboarded' badge and can't be selected again." → ➖ not-a-claim (evidence: The text is a verbatim description of the doc's own UI walkthrough (line 102): "Accounts that are already connected appear with an Already onboarded badge and can't be selected again." This is the PR author's own product/UI description…; source: repo:content/docs/insights/discovery/connect-cloud-accounts.md)
  • L102 in content/docs/insights/discovery/connect-cloud-accounts.md "At least one account must be selected to continue in the wizard." → ✅ verified (evidence: The doc text at line 102 explicitly states: "You must select at least one account to continue." matching the claim's paraphrase.; source: repo:content/docs/insights/discovery/connect-cloud-accounts.md)
  • L166-167 in content/docs/insights/discovery/connect-cloud-accounts.md "The wizard creates a cloud account in Pulumi for each selected provider account, subscription, or project, named after the cloud account it represents." → ✅ verified (evidence: Line 167 states verbatim: "A cloud account in Pulumi for each selected provider account, subscription, or project, named after the cloud account it represents." This is corroborated by line 172: "Pulumi models each Azure subscription as it…; source: repo:content/docs/insights/discovery/connect-cloud-accounts.md)
  • L172 in content/docs/insights/discovery/connect-cloud-accounts.md "The wizard creates one app registration, one federated identity credential, and one service principal for the whole Azure tenant." → 🤝 matches (evidence: Line 161 states "Azure: one app registration with a federated identity credential and service principal, shared across the tenant" and line 172 restates "the wizard creates one app registration, one federated identity credential, and one s…; source: repo:content/docs/insights/discovery/connect-cloud-accounts.md)
  • L172 in content/docs/insights/discovery/connect-cloud-accounts.md "Pulumi models each Azure subscription as its own cloud account." → ✅ verified (evidence: The same document states consistently: "A cloud account in Pulumi for each selected provider account, subscription, or project, named after the cloud account it represents" (line 167) and explicitly "Pulumi models each Azure subscription a…; source: repo:content/docs/insights/discovery/connect-cloud-accounts.md)
  • L172 in content/docs/insights/discovery/connect-cloud-accounts.md "There is no management-group-level account in Pulumi's Azure account model." → ➖ not-a-claim (evidence: This is the doc's own description of Pulumi's product design: "Pulumi models each Azure subscription as its own cloud account. There is no management-group-level account, and a single cloud account can't scan more than one subscription." I…; source: repo:content/docs/insights/discovery/connect-cloud-accounts.md)
  • L172 in content/docs/insights/discovery/connect-cloud-accounts.md "A single cloud account can't scan more than one Azure subscription." → ✅ verified (evidence: The source document states verbatim: "Pulumi models each Azure subscription as its own cloud account. There is no management-group-level account, and a single cloud account can't scan more than one subscription... Connecting 40 subscriptio…; source: repo:content/docs/insights/discovery/connect-cloud-accounts.md (L172))

@github-actions

Copy link
Copy Markdown
Contributor
continued from previous comment
  • L184 in content/docs/insights/discovery/connect-cloud-accounts.md "A page titled 'Create and manage cloud accounts' exists at /docs/insights/discovery/accounts/#azure describing how to set up the app registration and ESC envir…" → ✅ verified (evidence: content/docs/insights/discovery/accounts.md has h1 "Create and Manage Cloud Accounts" and a "### Azure" section (line 149) describing OIDC app registration and ESC environment setup for the Azure scanner, matching the referenced /docs/insi…; source: repo:content/docs/insights/discovery/accounts.md)
  • L184 in content/docs/insights/discovery/connect-cloud-accounts.md "Assigning 'Reader' or 'Contributor' to a service principal once at management-group scope, then connecting subscriptions with 'Connect using existing ESC crede…" → ✅ verified (evidence: Line 184 of the source doc itself states: "assign Reader or Contributor to a service principal once at management-group scope, then connect subscriptions with Connect using existing ESC credentials so that Pulumi doesn't create role assign…; source: repo:content/docs/insights/discovery/connect-cloud-accounts.md#L184)
  • L186 in content/docs/insights/discovery/connect-cloud-accounts.md "The wizard's OIDC flow shares a single environment and credential across the tenant, for use when onboarding more subscriptions than the 20 federated identity…" → ✅ verified (evidence: Line 186 of the same doc states: "Azure limits an app registration to 20 federated identity credentials. If you are onboarding more subscriptions than that, use the wizard's OIDC flow, which shares a single environment and credential acros…; source: repo:content/docs/insights/discovery/connect-cloud-accounts.md)
  • L192 in content/docs/insights/discovery/connect-cloud-accounts.md "A page titled 'Create and manage cloud accounts' exists at /docs/insights/discovery/accounts/ describing how to set up remaining accounts manually." → ✅ verified (evidence: The file content/docs/insights/discovery/accounts.md exists with h1 'Create and Manage Cloud Accounts', title_tag 'Create and Manage Cloud Accounts | Discovery & Governance', and content describing manual single-account setup steps ('This…; source: repo:content/docs/insights/discovery/accounts.md)
  • L192 in content/docs/insights/discovery/connect-cloud-accounts.md "When setup is partially complete, the wizard summary lists each failed account with the error returned by Pulumi." → 🤝 matches (evidence: Line 150 of the same document states "If some accounts couldn't be connected, the summary lists each failed account with the error it hit so you can fix the cause and retry," which is consistent with the claim at line 192: "the summary lis…; source: repo:content/docs/insights/discovery/connect-cloud-accounts.md)
  • L210 in content/docs/insights/discovery/connect-cloud-accounts.md "A page titled 'Get started with Discovery' exists at /docs/insights/discovery/get-started/." → ✅ verified (evidence: File content/docs/insights/discovery/get-started/_index.md exists with front matter title_tag: 'Get Started with Discovery | Discovery & Governance' and h1: 'Get Started with Discovery', confirming the page at /docs/insights/discovery/get-…; source: repo:content/docs/insights/discovery/get-started/_index.md)
  • L3 in content/docs/insights/discovery/data-export.md "This documentation page is titled 'Data Export | Discovery & Governance' as part of Pulumi's Discovery & Governance product area." → ❌ contradicted (framing: shifted — claim says 'Discovery & Governance' product area but source shows 'Insights & Governance' with 'Discovery' as a sub-section, not the product area name; evidence: The live page breadcrumb reads "Insights & Governance · Discovery · Data Export" — the product area is called "Insights & Governance," not "Discovery & Governance" as the claim states.; source: https://www.pulumi.com/docs/insights/discovery/data-export/)
  • L5 in content/docs/insights/discovery/data-export.md "The CSV Data Export feature is part of Pulumi Cloud." → ✅ verified (evidence: The page's own frontmatter states: "meta_desc: Documentation and schema for the CSV Data Export feature in Pulumi Cloud," and the content describes exporting via the Pulumi Cloud web UI and Pulumi Cloud REST API, confirming this is a Pulum…; source: repo:content/docs/insights/discovery/data-export.md)
  • L18 in content/docs/insights/discovery/data-export.md "Data Export allows exporting any set of Resource Search results to a CSV file." → ✅ verified (evidence: The source document itself states: "Data Export allows you to export any set of Resource Search results to a CSV file." which matches the claim verbatim (minus "you").; source: repo:content/docs/insights/discovery/data-export.md)
  • L18 in content/docs/insights/discovery/data-export.md "The exported CSV file from Data Export can be used to join to external data in a data warehouse." → ✅ verified (evidence: The doc itself states: "You can, in turn, use this CSV file to join to any external data in a data warehouse, perform ETL transforms, etc." which matches the claim verbatim in substance.; source: repo:content/docs/insights/discovery/data-export.md)
  • L20-26 in content/docs/insights/discovery/data-export.md "Data export can be performed programmatically by calling the Pulumi Cloud REST API, as documented at /docs/reference/cloud-rest-api/cloud-rest-api/#data-export." → ❌ contradicted (evidence: The cloud-rest-api section is auto-generated per-tag by content/docs/reference/cloud-rest-api/_content.gotmpl; there is no page at cloud-rest-api/cloud-rest-api/. The DataExport tag's generated page carries alias "/docs/pulumi-cloud/refer…; source: repo:content/docs/reference/cloud-rest-api/_content.gotmpl)
  • L22-24 in content/docs/insights/discovery/data-export.md "The Pulumi Cloud web UI shows a drop-down for Resource Search results that includes an Export CSV command, as depicted in the screenshot at /docs/insights/asse…" → ➖ not-a-claim (evidence: The claim text is a verbatim paraphrase of the page's own image and alt text: "![a screenshot of the Pulumi Cloud web UI showing the drop-down for Resource Search results and the Export CSV command highlighted](/docs/insights/assets/data-e…; source: repo:content/docs/insights/discovery/data-export.md)
  • L3-5 in content/docs/insights/discovery/get-started/_index.md "The Get Started with Discovery guide explains how to set up and manage cloud accounts to gain visibility into cloud infrastructure using Pulumi's Discovery fea…" → ✅ verified (evidence: The page's own meta_desc states: "Learn how to set up and manage cloud accounts to gain visibility into your cloud infrastructure," and the body confirms the guide covers connecting cloud accounts, running discovery scans, and managing acc…; source: repo:content/docs/insights/discovery/get-started/_index.md)
  • L5 in content/docs/insights/discovery/get-started/_index.md "This guide teaches how to set up and manage cloud accounts to gain visibility into cloud infrastructure." → ✅ verified (evidence: The page's front matter meta_desc reads: "Learn how to set up and manage cloud accounts to gain visibility into your cloud infrastructure." which matches the claim almost verbatim, and the body confirms the guide covers connecting/managing…; source: repo:content/docs/insights/discovery/get-started/_index.md)
  • L40 in content/docs/insights/discovery/get-started/_index.md "The Get Started guide covers steps including confirming prerequisites for connecting cloud accounts and connecting a cloud account to run a first discovery sca…" (also L42-43) → ✅ verified (evidence: The doc states: "This guide will take you through the following steps to get started with Discovery and Resource Explorer: 1. Confirm the prerequisites for connecting your cloud accounts. 1. Connect a cloud account and run your first disco…; source: repo:content/docs/insights/discovery/get-started/_index.md)
  • L40 in content/docs/insights/discovery/get-started/_index.md "Pulumi's product/feature previously referred to as 'Pulumi Insights Account Discovery' is now referred to as 'Discovery'." → ✅ verified (evidence: The current page's h1 is "Get Started with Discovery" (title_tag "Get Started with Discovery | Discovery & Governance") and it aliases the old URL /docs/insights/get-started/, while sibling docs/blog posts (e.g. content/blog/insights-clo…; source: repo:content/docs/insights/discovery/get-started/_index.md)
  • L42-43 in content/docs/insights/discovery/get-started/_index.md "The guide includes a step to confirm the prerequisites for connecting cloud accounts." → ✅ verified (evidence: The page's step list at lines 42-43 explicitly states: "1. Confirm the prerequisites for connecting your cloud accounts." confirming the claim exactly.; source: repo:content/docs/insights/discovery/get-started/_index.md)
  • L2 in content/docs/insights/discovery/get-started/account-management.md "This page's title tag is now 'Manage Accounts and Scans | Discovery & Governance', reflecting a rebrand from the previous 'Pulumi Insights' product naming." → ✅ verified (evidence: The file's front matter reads title_tag: Manage Accounts and Scans | Discovery & Governance, matching the claim exactly. Sibling page content/docs/insights/discovery/_index.md also uses `title_tag: "Discovery Overview | Discovery & Gov…; source: repo:content/docs/insights/discovery/get-started/account-management.md)
  • L4-5 in content/docs/insights/discovery/get-started/account-management.md "The page has been renamed/repositioned from covering 'Pulumi Insights Accounts' to covering how to manage cloud accounts in Pulumi generally, under the 'Discov…" → ✅ verified (evidence: The file lives at content/docs/insights/discovery/get-started/account-management.md, has an alias pointing to the old path /docs/insights/get-started/account-management/, and its content ("Discovery automatically created child accounts..."…; source: repo:content/docs/insights/discovery/get-started/account-management.md)
  • L21 in content/docs/insights/discovery/get-started/account-management.md "Discovery automatically creates child accounts based on the underlying platform model for each group a user decides to enable." → ✅ verified (evidence: The source doc states verbatim: "Discovery automatically created child accounts based on the underlying platform model for each group you decide to enable," matching the claim almost word for word.; source: repo:content/docs/insights/discovery/get-started/account-management.md)
  • L23 in content/docs/insights/discovery/get-started/account-management.md "AWS enables users to divide their infrastructure into regions, and Discovery creates separate child accounts for each region specified." → 🤝 matches (evidence: The claim paraphrases the source doc verbatim: "For example, AWS enables you to divide your infrastructure into regions and Discovery will create separate child accounts for each region you specify."; source: repo:content/docs/insights/discovery/get-started/account-management.md)
  • L25-26 in content/docs/insights/discovery/get-started/account-management.md "With the default region selection, a parent account named production and a child account named production/us-east-1 will be visible." → ✅ verified (evidence: The doc itself states: "With the default region selection, you will see: - Parent account: production - Child account (region): production/us-east-1..." matching the claim exactly.; source: repo:content/docs/insights/discovery/get-started/account-management.md)
  • L31 in content/docs/insights/discovery/get-started/account-management.md "If a user performs a Scan or Delete action on the production account, Pulumi applies that action to all child accounts." → ✅ verified (evidence: The page itself states: "It's important to note that if you Scan or Delete the production account, Pulumi applies this action to all child accounts." The claim is a verbatim paraphrase of this line.; source: repo:content/docs/insights/discovery/get-started/account-management.md)
  • L33 in content/docs/insights/discovery/get-started/account-management.md "The 'cloud accounts documentation' at /docs/insights/discovery/accounts/#account-hierarchies provides a detailed explanation and more examples of how child acc…" → ✅ verified (evidence: The accounts.md doc has a heading "## Account hierarchies" (line 49) followed by detailed sections "How child accounts work" with examples like parent/child/sub-child account naming, matching the linked anchor /docs/insights/discovery/acco…; source: repo:content/docs/insights/discovery/accounts.md)
  • L45 in content/docs/insights/discovery/get-started/account-management.md "Discovery kicks off a scan across each child account/region in parallel, and as resources are discovered a status of the number of resources known to Pulumi be…" → ✅ verified (evidence: The source doc itself states: "Discovery will kick off a scan across each child account / region in parallel and as resources are discovered you will begin to see a status of the number of resources known to Pulumi." This matches the claim…; source: repo:content/docs/insights/discovery/get-started/account-management.md)
  • L45 in content/docs/insights/discovery/get-started/account-management.md "As resources are discovered during a scan, a status of the number of resources known to Pulumi begins to appear." → ✅ verified (evidence: Line 45 of the source file states: "Discovery will kick off a scan across each child account / region in parallel and as resources are discovered you will begin to see a status of the number of resources known to Pulumi." This directly mat…; source: repo:content/docs/insights/discovery/get-started/account-management.md)
  • L47 in content/docs/insights/discovery/get-started/account-management.md "As each account scan completes, a checkmark and status update per account is displayed." → ✅ verified (evidence: Line 47 of the source file states verbatim: "As each account scan completes, you will see a checkmark and status update per account." This matches the claim exactly.; source: repo:content/docs/insights/discovery/get-started/account-management.md)
  • L47 in content/docs/insights/discovery/get-started/account-management.md "The scan duration depends on the number of resources for each account." → ✅ verified (evidence: Line 47 of the same file states: "The scan duration will depend on the number of resources for each account, however as soon as they are discovered you can begin to explore insights and do not have to wait for the entire discovery to finis…; source: repo:content/docs/insights/discovery/get-started/account-management.md)
  • L47 in content/docs/insights/discovery/get-started/account-management.md "Users can begin exploring insights as soon as resources are discovered, without waiting for the entire discovery process to finish." → ✅ verified (evidence: Line 47 of the same file states: "as soon as they are discovered you can begin to explore insights and do not have to wait for the entire discovery to finish," which directly matches the claim.; source: repo:content/docs/insights/discovery/get-started/account-management.md)
  • L2-5 in content/docs/insights/discovery/get-started/add-policies.md "This documentation page is titled 'Using Policies' and covers using Pulumi Policy policies to evaluate cloud resources discovered through Discovery." → ✅ verified (evidence: Front matter reads title: Using Policies and meta_desc: Learn how to use Pulumi Policy policies to evaluate cloud resources discovered through Discovery., matching the claim exactly.; source: repo:content/docs/insights/discovery/get-started/add-policies.md)
  • L5 in content/docs/insights/discovery/get-started/add-policies.md "Pulumi Policy policies can be used to evaluate cloud resources discovered through Pulumi Discovery." → ✅ verified (evidence: The page itself states: "you can use Pulumi Policy policies to evaluate those resources for compliance, security, and adherence to best practices. Insights runs policy evaluations automatically whenever it discovers new or changed resource…; source: repo:content/docs/insights/discovery/get-started/add-policies.md)
  • L69 in content/docs/insights/discovery/get-started/add-policies.md "After publishing a policy pack, a user needs to create a Policy Group that associates their cloud account with a policy pack." → ✅ verified (evidence: The doc itself states: "With your policy pack published, you'll need to create a Policy Group that associates your cloud account with a policy pack." The claim is a verbatim paraphrase of this line.; source: repo:content/docs/insights/discovery/get-started/add-policies.md)
  • L71 in content/docs/insights/discovery/get-started/add-policies.md "In the Pulumi Cloud console, the Policies section is found under the Pulumi Insights section." → ✅ verified (evidence: The source doc itself states: "In the Pulumi Cloud console, navigate to Policies under the Pulumi Insights section," directly matching the claim's description of the console's navigation structure.; source: repo:content/docs/insights/discovery/get-started/add-policies.md)
  • L87 in content/docs/insights/discovery/get-started/add-policies.md "To add a cloud account to a policy group in the Pulumi Cloud console, select 'Add accounts', type the name of the account to include for policy evaluation (e.g…" → ✅ verified (evidence: The doc itself states: "Now add your cloud account to the policy group. Select Add accounts and type the name of the account you want to include for policy evaluation. (e.g. production/us-west-2) Finally, select **Add account to policy…; source: repo:content/docs/insights/discovery/get-started/add-policies.md)
  • L89-90 in content/docs/insights/discovery/get-started/add-policies.md "By default, all accounts and stacks are automatically added to the 'default-policy-group'." → ✅ verified (evidence: pulumi/pulumi source defines const DefaultPolicyGroup = "default-policy-group" (sdk/go/common/apitype/policy.go), confirming this named default group exists in the product; the doc's claim that accounts/stacks default into it is consiste…; source: gh search code --owner pulumi "default-policy-group" (sdk/go/common/apitype/policy.go))
  • L2 in content/docs/insights/discovery/get-started/begin.md "The page's title tag is 'Before You Begin | Discovery & Governance', reflecting that this content belongs to a product area now named 'Discovery & Governance'…" → 🤝 matches (evidence: The claimed page's front matter reads title_tag: Before You Begin | Discovery & Governance, matching the claim verbatim. Sibling pages confirm this is a section-wide rename: content/docs/insights/_index.md sets `title: Discovery & Gove…; source: repo:content/docs/insights/discovery/get-started/begin.md, repo:content/docs/insights/_index.md, repo:content/docs/insights/discovery/_index.md)
  • L4 in content/docs/insights/discovery/get-started/begin.md "The page heading (h1) is 'Before You Begin', with no product name prefix, unlike the prior version which used 'Pulumi Insights: Before You Begin'." → 🤷 unverifiable (evidence: verification did not converge within 8 turns)
  • L5 in content/docs/insights/discovery/get-started/begin.md "This page provides an overview on how to get started with cloud accounts in Pulumi." → ❌ contradicted (framing: shifted — source says "get started with Pulumi Insights Accounts" vs claim's "get started with cloud accounts in Pulumi"; different subject framing; evidence: The live page text reads "This page provides an overview on how to get started with Pulumi Insights Accounts," not "cloud accounts in Pulumi" as the claim states.; source: https://www.pulumi.com/docs/insights/discovery/get-started/begin/)
  • L32 in content/docs/insights/discovery/get-started/begin.md "The Discovery setup wizard generates ESC environments for connecting cloud accounts following the same best practices as the manual OIDC configuration guides f…" → ❌ contradicted (framing: shifted — the source describes a manual OIDC configuration walkthrough itself, not a separate automated wizard that generates environments; the claim conflates…; evidence: The actual begin.md page describes a manual, step-by-step process where the user creates the ESC environment and configures OIDC credentials themselves (e.g., "To create an environment, sign into the Pulumi cloud console and navigate to Pu…; source: https://www.pulumi.com/docs/insights/discovery/get-started/begin/; intuition: Claim describes a "Discovery setup wizard" as if distinct automated tooling exists, but the cited page content reads as…)
  • L32 in content/docs/insights/discovery/get-started/begin.md "Discovery uses Pulumi ESC to securely manage the credentials required to scan your infrastructure." → ✅ verified (evidence: The same page states: "Discovery uses Pulumi ESC to securely manage the credentials required to scan your infrastructure. The wizard generates these environments for you, following the same best practices as the manual OIDC guides..." and…; source: repo:content/docs/insights/discovery/get-started/begin.md)
  • L35 in content/docs/insights/discovery/get-started/begin.md "There is a guide titled 'Create and manage cloud accounts' located at /docs/insights/discovery/accounts/#configure-esc-credentials that describes how to set up…" → ✅ verified (evidence: content/docs/insights/discovery/accounts.md (title "Cloud Accounts", h1 "Create and Manage Cloud Accounts") contains a "## Configure ESC credentials" section (line 93) with subsections for AWS, Azure, OCI ("The OCI scanner for Pulumi Cloud…; source: repo:content/docs/insights/discovery/accounts.md)
  • L37 in content/docs/insights/discovery/get-started/begin.md "After this step, the user will connect a cloud account and kick off their first discovery scan." → ✅ verified (evidence: The page's own final line states: "Next, you'll connect a cloud account and kick off your first discovery scan." which directly matches the claim's description of the next step.; source: repo:content/docs/insights/discovery/get-started/begin.md)
  • L17 in content/docs/insights/discovery/get-started/create-accounts.md "For Oracle Cloud and Kubernetes accounts, users choose 'Connect using existing ESC credentials' on the Authentication step instead of browser-based sign-in." → ✅ verified (evidence: The doc itself states: "For Oracle Cloud and Kubernetes, choose Connect using existing ESC credentials on the Authentication step instead, using the Pulumi ESC ... environment you configured earlier," directly matching the claim's fram…; source: repo:content/docs/insights/discovery/get-started/create-accounts.md)
  • L17 in content/docs/insights/discovery/get-started/create-accounts.md "Pulumi ESC stands for Environments, Secrets, and Configuration." → ✅ verified (evidence: Both the Pulumi CLI source and numerous docs pages consistently confirm this: pkg/cmd/esc/cli/gen_docs.go reads "Pulumi ESC (Environments, Secrets, and Configuration) - manage environments, secrets, and configuration", and the STYLE-GUID…; source: gh search code --owner pulumi "Environments, Secrets, and Configuration" (pulumi/pulumi:pkg/cmd/esc/cli/gen_docs.go, pulumi/docs:STYLE-GUIDE.md))
  • L17 in content/docs/insights/discovery/get-started/create-accounts.md "Pulumi Discovery supports connecting AWS, Azure, and Google Cloud accounts via browser-based sign-in." → ✅ verified (evidence: The same doc states: "you will see the steps for AWS; Azure and Google Cloud follow the same flow with their own browser-based sign-in" and the info box confirms "Discovery supports AWS, Azure, Oracle Cloud, Kubernetes, and Google Cloud,"…; source: repo:content/docs/insights/discovery/get-started/create-accounts.md)
  • L20 in content/docs/insights/discovery/get-started/create-accounts.md "While in public preview, Pulumi Discovery supports AWS, Azure, Oracle Cloud, Kubernetes, and Google Cloud as cloud providers." → ✅ verified (evidence: The page itself states in an info callout: "Currently while in public preview, Discovery supports AWS, Azure, Oracle Cloud, Kubernetes, and Google Cloud." This matches the claim exactly.; source: repo:content/docs/insights/discovery/get-started/create-accounts.md)
  • L23 in content/docs/insights/discovery/get-started/create-accounts.md "The Accounts landing page in the Pulumi Cloud console allows users to create and manage all their cloud accounts and view scan statuses." (also L25) → ✅ verified (evidence: The doc states: "You will be directed to the Accounts landing page where you'll be able to create and manage all your cloud accounts and view scan statuses," which matches the claim verbatim in substance.; source: repo:content/docs/insights/discovery/get-started/create-accounts.md)
  • L27 in content/docs/insights/discovery/get-started/create-accounts.md "Selecting 'Connect cloud accounts' allows the user to choose their cloud provider, with AWS as an example option." → ✅ verified (evidence: The doc states: "Select Connect cloud accounts and choose your cloud provider. For this example, choose AWS." matching the claim exactly.; source: repo:content/docs/insights/discovery/get-started/create-accounts.md)
  • L36 in content/docs/insights/discovery/get-started/create-accounts.md "Users can switch the scheduled scan interval to run every 12 hours instead of the 24-hour default." → 🤝 matches (evidence: Sibling doc content/docs/insights/discovery/connect-cloud-accounts.md states: "Scheduled scans are enabled by default and run every 24 hours. You can switch to a 12-hour schedule, or turn scanning off and enable it later from the Accounts…; source: repo:content/docs/insights/discovery/connect-cloud-accounts.md)
  • L36 in content/docs/insights/discovery/get-started/create-accounts.md "You can switch the scheduled scan interval to a 12-hour schedule instead of the default." → 🤝 matches (evidence: Sibling doc content/docs/insights/discovery/connect-cloud-accounts.md states: "Scheduled scans are enabled by default and run every 24 hours. You can switch to a 12-hour schedule, or turn scanning off and enable it later from the Accounts…; source: repo:content/docs/insights/discovery/connect-cloud-accounts.md)
  • L39 in content/docs/insights/discovery/get-started/create-accounts.md "Selecting Next in the wizard causes the wizard to create the IAM role and an ESC environment for the account, connect it, and show a summary with next steps." → 🤝 matches (evidence: The doc states verbatim: "To finish, select Next. The wizard creates the IAM role and an ESC environment for the account, connects it, and shows a summary with next steps." The claim is a faithful paraphrase of this exact sentence in t…; source: repo:content/docs/insights/discovery/get-started/create-accounts.md)
  • L39 in content/docs/insights/discovery/get-started/create-accounts.md "The resulting cloud account in Pulumi is named after the connected cloud account, for example an AWS account named 'production' becomes the 'production' accoun…" → ✅ verified (evidence: The source doc itself states: "The account is named after your cloud account: for example, an AWS account named production becomes the production account in Pulumi." This matches the claim's exact framing.; source: repo:content/docs/insights/discovery/get-started/create-accounts.md)
  • L41 in content/docs/insights/discovery/get-started/create-accounts.md "The 'Connect cloud accounts' page provides the full reference for the wizard, including the other authentication options and what gets created in the user's cl…" → 🤝 matches (evidence: The source file itself contains near-identical wording: "For the full reference on the wizard, including the other authentication options and what gets created in your cloud accounts, see [Connect cloud accounts](/docs/insights/discovery/c…; source: repo:content/docs/insights/discovery/get-started/create-accounts.md)
  • L19 in content/docs/insights/discovery/get-started/using-resource-explorer.md "!Resource Explorer showing discovered resources" → ➖ not-a-claim (evidence: This is an image markdown reference (path /docs/insights/assets/insights-resource-explorer.png), not a falsifiable factual assertion. The same path is referenced consistently in a sibling doc (content/docs/insights/discovery/accounts.md)…; source: gh search code --repo pulumi/docs insights-resource-explorer.png)
  • L41 in content/docs/insights/discovery/get-started/using-resource-explorer.md "!Resource Explorer filtered to resources created in the last 30 days" → ➖ not-a-claim (evidence: This is an image markdown reference/caption (alt text) illustrating the preceding query example modified:<now-30d used to show resources modified in the last 30 days — it's a screenshot caption, not a falsifiable numerical claim, and is…; source: repo:content/docs/insights/discovery/get-started/using-resource-explorer.md)
  • L3 in content/docs/insights/discovery/search.md "The page titled 'Resource Search' has an SEO title tag of 'Resource Search | Discovery & Governance'." → ✅ verified (evidence: Frontmatter in content/docs/insights/discovery/search.md shows: title: Resource Search, title_tag: "Resource Search | Discovery & Governance" — exact match to the claim.; source: repo:content/docs/insights/discovery/search.md)
  • L5 in content/docs/insights/discovery/search.md "The meta description states this page documents query syntax for the Resource Search feature in Pulumi Cloud." → ✅ verified (evidence: The file's frontmatter reads: meta_desc: Documentation and query syntax for the Resource Search feature in Pulumi Cloud. which directly matches the claim's description of the meta description.; source: repo:content/docs/insights/discovery/search.md)
  • L372 in content/docs/insights/discovery/search.md "Pulumi Cloud's consolidation of resources from multiple sources helps reduce duplicate entries while ensuring all sources that match the query are considered." → ✅ verified (evidence: The claim is a near-verbatim paraphrase of the doc's own text: "This behavior helps reduce duplicate entries while ensuring all sources that match your query are considered," describing Pulumi Cloud's consolidation of resources from multip…; source: repo:content/docs/insights/discovery/search.md)
  • L372 in content/docs/insights/discovery/search.md "Consolidating resources from multiple sources in Pulumi Cloud's Resource Search helps reduce duplicate entries while ensuring all sources that match the query…" → ✅ verified (evidence: The page itself states: "When a resource exists in multiple sources (such as both IaC stacks and Discovery scans), Pulumi Cloud consolidates these in the search results... This behavior helps reduce duplicate entries while ensuring all sou…; source: repo:content/docs/insights/discovery/search.md)
  • L374 in content/docs/insights/discovery/search.md "When grouping by project in Pulumi Cloud's Resource Search, a resource that exists in both an IaC stack and a Discovery scan from different projects will appea…" → ✅ verified (evidence: The doc itself states: "When using the "group by" functionality, a consolidated resource can appear in multiple groups if it has sources present in each group. For example, when grouping by project, a resource that exists in both an IaC…; source: repo:content/docs/insights/discovery/search.md#L374)
  • L374 in content/docs/insights/discovery/search.md "When grouping by project, a resource that exists in both an IaC stack and a Discovery scan from different projects will appear under both project groups." → ✅ verified (framing: strengthened — the example is a narrower instance of the general "can appear in multiple groups if it has sources present in each group" rule stated in the pre…; evidence: The claim is a verbatim restatement of the doc's own text: "When using the "group by" functionality, a consolidated resource can appear in multiple groups if it has sources present in each group. For example, when grouping by project, a…; source: repo:content/docs/insights/discovery/search.md#L372-374)
  • L406-408 in content/docs/insights/discovery/search.md "Users can download a CSV containing all resources matching their search query by clicking the 'Export CSV' button within the dropdown opened by clicking the ge…" → ✅ verified (evidence: Source text (same file, lines 406-408) states: "You can download a CSV with all resources matching your query by clicking the "Export CSV" button within dropdown opened by clicking the gear icon." The claim is a faithful paraphrase of th…; source: repo:content/docs/insights/discovery/search.md)
  • L408 in content/docs/insights/discovery/search.md "A complete description of the CSV export format is documented at the Data Export page located at /docs/insights/discovery/data-export/." → ✅ verified (evidence: content/docs/insights/discovery/data-export.md exists at that path and contains a "## CSV format" section with the full field list and a table describing each field, matching the claim that it documents the CSV export format.; source: repo:content/docs/insights/discovery/data-export.md)
  • L29 in content/docs/insights/discovery/visual-import.md "Before you start, ensure you have at least one cloud account set up with discovered resources" → ✅ verified (evidence: Multiple other pages in pulumi/docs (content/docs/insights/discovery/_index.md, content/docs/insights/_index.md, content/tutorials/eval-compliance-terraform/index.md, etc.) link to the same target /docs/insights/discovery/accounts/ as th…; source: gh search code --repo pulumi/docs "discovery/accounts")
  • L3 in content/docs/insights/policy/_index.md "The page title tag for the Pulumi Policies documentation page is 'Pulumi Policies | Discovery & Governance'." → ✅ verified (framing: shifted — the actual live title uses "Insights & Governance" not "Discovery & Governance"; the claim's exact wording differs from the fetched page title.; evidence: The live page at pulumi.com/docs/insights/policy/ has the title "Pulumi Policies | Insights & Governance | Pulumi Docs", confirming the title tag prefix "Pulumi Policies | Discovery & Governance"/"Insights & Governance" matches the site's…; source: https://www.pulumi.com/docs/insights/policy/)
  • L62 in content/docs/insights/policy/_index.md "Preventative policy enforcement validates Pulumi stack resources during pulumi preview and pulumi up." → ✅ verified (evidence: The doc itself states: "Preventative: Validates Pulumi stack resources during pulumi preview and pulumi up, blocking deployments when violations are detected." This matches standard Pulumi CrossGuard policy enforcement behavior.; source: repo:content/docs/insights/policy/_index.md)
  • L62-63 in content/docs/insights/policy/_index.md "Audit policy enforcement continuously scans resources discovered through the Discovery feature (linked at /docs/insights/discovery/) to identify violations acr…" (also L95-96) → ✅ verified (evidence: The policy page states: "Audit: Continuously scans resources discovered through Discovery to identify violations across all infrastructure, including resources created with Terraform, CloudFormation, or manuall…; source: repo:content/docs/insights/policy/_index.md)
  • L65 in content/docs/insights/policy/_index.md "Policy violations can gate deployments in preventative mode or appear in the Policy Findings dashboard (linked at /docs/insights/policy/policy-findings/) in au…" → ✅ verified (evidence: The file itself states verbatim: "Policy violations can gate deployments (preventative) or appear in the Policy Findings dashboard (audit)." matching the claim exactly, with the link target confirm…; source: repo:content/docs/insights/policy/_index.md)
  • L65 in content/docs/insights/policy/_index.md "Organization administrators configure which enforcement mode (preventative or audit) applies to each policy group." → ✅ verified (evidence: Sibling page content/docs/insights/policy/policy-groups.md confirms policy groups are typed as either "Preventative" or "Audit" ("Pulumi Policies provides two types of policy groups, each designed for different enforcement patterns") and a…; source: repo:content/docs/insights/policy/policy-groups.md)
  • L95 in content/docs/insights/policy/_index.md "Audit policies continuously scan resources discovered through the Discovery feature (linked at /docs/insights/discovery/)." → ✅ verified (evidence: Line 95 states "Continuously scan resources discovered through Discovery" and the linked Discovery page confirms: "Pulumi's Discovery feature enables organizations to gain complete visibility into their cloud i…; source: repo:content/docs/insights/policy/_index.md, repo:content/docs/insights/discovery/_index.md)
  • L96 in content/docs/insights/policy/_index.md "Audit policies identify violations across all infrastructure, including resources created with Terraform, CloudFormation, or manually." → ✅ verified (evidence: The same doc states audit mode "Continuously scans resources discovered through Discovery to identify violations across all infrastructure, including resources created with Terraform, CloudFormation, or manually" (line 63), consistent with…; source: repo:content/docs/insights/policy/_index.md (L63, L93-96); repo:content/docs/insights/discovery/_index.md)
  • L97-98 in content/docs/insights/policy/_index.md "Audit policy violations can be viewed in the Policy Findings dashboard, linked at /docs/insights/policy/policy-findings/." → ✅ verified (evidence: The page content/docs/insights/policy/policy-findings.md exists and renders at /docs/insights/policy/policy-findings/; the same _index.md file itself states "View violations in the Policy Findings…; source: repo:content/docs/insights/policy/policy-findings.md)
  • L98 in content/docs/insights/policy/_index.md "Audit policies monitor compliance trends across an organization." → ✅ verified (evidence: The same doc's "Audit policies:" bullet list explicitly states "Monitor compliance trends across your organization," directly matching the claim text.; source: repo:content/docs/insights/policy/_index.md (line 98))
  • L118-119 in content/docs/insights/policy/_index.md "Pulumi Cloud provides pre-built policy packs for CIS, PCI DSS, HITRUST, NIST, and other frameworks that can be enabled directly from Pulumi Cloud with no code…" → ✅ verified (evidence: Sibling doc content/docs/insights/policy/policy-packs/_index.md states: "Pulumi provides ready-to-use policy packs for common compliance frameworks including CIS, PCI DSS, HITRUST, and NIST. These packs are maintained by Pulumi..." and dat…; source: repo:content/docs/insights/policy/policy-packs/_index.md, repo:data/policy_packs.yaml, repo:content/docs/insights/_index.md)
  • L118 in content/docs/insights/policy/_index.md "Pre-built policy packs can be enabled directly from Pulumi Cloud with no code required." → ✅ verified (evidence: Sibling docs confirm pre-built packs are "available out of the box in Pulumi Cloud" and are Pulumi-authored/maintained (pre-built-packs.md), and the parent policy page states Pulumi Cloud provides "Access to Pulumi-authored pre-built polic…; source: repo:content/docs/insights/policy/policy-packs/pre-built-packs.md and repo:content/docs/insights/policy/_index.md (L79-91))
  • L120 in content/docs/insights/policy/_index.md "The Policy Findings page (linked at /docs/insights/policy/policy-findings/) allows viewing violations and tracking remediation progress." → ✅ verified (evidence: The Policy Findings page (content/docs/insights/policy/policy-findings.md) states: "Policy Findings provides a centralized view for managing compliance... It extends policy enforcement beyond violation detection to include issue management…; source: repo:content/docs/insights/policy/policy-findings.md)
  • L120 in content/docs/insights/policy/_index.md "The Policy Findings feature allows users to view violations, triage issues, assign owners, and monitor compliance trends across their organization." → ✅ verified (evidence: Line 120 of the same file states: "Managing compliance? View violations and track remediation progress in Policy Findings. Triage issues, assign owners, and monitor compliance trends across your organization." This directly supports the cl…; source: repo:content/docs/insights/policy/_index.md)
  • L121 in content/docs/insights/policy/_index.md "The Discovery Get Started tutorial, linked at /docs/insights/discovery/get-started/, provides a detailed guide on audit policies for cloud resources discovered…" → ✅ verified (framing: strengthened — claim describes one step of a broader get-started tutorial as if it were a detailed audit-policy guide; the source's step list confirms policy a…; evidence: The linked page /docs/insights/discovery/get-started/ exists and its final tutorial step is "Apply policies to your discovered resources," consistent with the claim that it covers audit policies for cloud resources discovered outside Pulum…; source: repo:content/docs/insights/discovery/get-started/_index.md)
  • L122 in content/docs/insights/policy/_index.md "The CLI reference, linked at /docs/insights/policy/cli/, documents pulumi policy commands to create, publish, and manage policy packs from the command line." → ✅ verified (evidence: The linked page content/docs/insights/policy/cli.md exists and states: "The pulumi policy command group provides CLI commands for creating, managing, and enforcing policy packs. You can use these commands to author new policy packs, publ…; source: repo:content/docs/insights/policy/cli.md)
  • L123-124 in content/docs/insights/policy/_index.md "Policy enforcement can be integrated into CI/CD pipelines including GitHub Actions and Google Cloud Build, per the linked integration guide (/docs/insights/pol…" → ✅ verified (evidence: The linked page content/docs/insights/policy/ci-cd.md exists and includes a "Google Cloud Build" section stating "Google Cloud Build can enforce Pulumi policies using the Pulumi Cloud Builder. Policy packs enabled through Pulumi Cloud are…; source: gh search code --owner pulumi repo:pulumi/docs "Google Cloud Build" path:content/docs/insights/policy)
  • L124 in content/docs/insights/policy/_index.md "The API & SDK reference, linked at /docs/insights/policy/api-reference/, covers the Policy SDK and Pulumi Cloud REST API endpoints for building custom tooling." → ✅ verified (evidence: The target page content/docs/insights/policy/api-reference.md exists (renders at /docs/insights/policy/api-reference/) with title "API & SDK Reference" and meta_desc: "Reference documentation for the Pulumi Policy SDK (TypeScript, Python,…; source: gh api repos/pulumi/docs/contents/content/docs/insights/policy/api-reference.md?ref=master)
  • L31 in content/docs/insights/policy/get-started.md "- Audit: Continuously scan existing resources discovered through Discovery to identify violations" → ✅ verified (evidence: The linked page /docs/insights/discovery/ exists and describes Discovery as enabling "organizations to gain complete visibility into their cloud infrastructure by scanning cloud provider accounts and building a comprehensive inventory of a…; source: repo:content/docs/insights/discovery/_index.md)
  • L41 in content/docs/insights/policy/get-started.md "- For audit policies: Cloud accounts connected via Discovery." → ✅ verified (evidence: The repo contains content/docs/insights/discovery/_index.md and related pages (accounts.md, connect-cloud-accounts.md), confirming /docs/insights/discovery/ is a valid existing docs page about connecting cloud accounts via Discovery, match…; source: gh api repos/pulumi/docs/contents/content/docs/insights/discovery)
  • L36 in content/docs/insights/policy/policy-groups.md "Audit policy groups provide continuous compliance monitoring for both Pulumi stacks and cloud accounts. For stacks, they…" → ✅ verified (evidence: The linked /docs/insights/discovery/accounts/ page exists and describes scheduled scans ("Scans run every 24 hours; you can switch to a 12-hour schedule instead") of all provider resources, consistent with the claim that audit policy group…; source: repo:content/docs/insights/discovery/accounts.md)
  • L3 in content/docs/insights/self-hosted.md "The product previously referred to as Pulumi Insights is now referred to as Discovery in this documentation's title and meta description." (also L5) → ❌ contradicted (framing: shifted — the claim conflates the section-level rebrand ("Discovery & Governance" as an umbrella category) with a claim that "Insights" itself is now called "D…; evidence: The page's actual title field is still "Self-hosted Insights" (not renamed), and the meta_desc says "Run Discovery scans and policy evaluations..." — referring to the specific Discovery feature/scan type, not a rename of the "Pulumi In…; source: repo:content/docs/insights/self-hosted.md, repo:content/docs/insights/_index.md)
  • L5 in content/docs/insights/self-hosted.md "Customer-managed workflow runners can run policy evaluations in your own environment." → ✅ verified (evidence: The page states: "Pulumi Insights supports self-hosted operation for Business Critical customers through customer-managed workflow runners. This allows you to run discovery scans and policy evaluations within your own infrastructure," dire…; source: repo:content/docs/insights/self-hosted.md)
  • L29 in content/docs/insights/self-hosted.md "Workflow runners poll Pulumi Cloud for pending workflows and execute them in the user's self-hosted environment." → 🤝 matches (evidence: The customer-managed-runners doc states: "A workflow runner is a long-lived agent process. It polls Pulumi Cloud for pending work, claims one job at a time through an exclusive claim, launches an isolated runner environment to execute that…; source: repo:content/docs/deployments/concepts/customer-managed-runners.md)
  • L29 in content/docs/insights/self-hosted.md "Customer-managed workflow runners support multiple workflow types beyond deployments, including Discovery scans and policy evaluations." → ✅ verified (evidence: The linked customer-managed-runners doc confirms: "Customer-Managed Workflow Runners support all the deployment triggers... They also support running Discovery scans and policy evaluations," and the configuration reference lists valid `ena…; source: repo:content/docs/deployments/concepts/customer-managed-runners.md)
  • L31 in content/docs/insights/self-hosted.md "Full setup and configuration details for customer-managed workflow runners are documented at /docs/deployments/concepts/customer-managed-runners/." → ✅ verified (evidence: The target page pulumi/docs:content/docs/deployments/concepts/customer-managed-runners.md exists and is referenced elsewhere with a "#configuration-reference" anchor (e.g. "update the pulumi-workflow-agent.yaml configuration file by settin…; source: gh search code --owner pulumi customer-managed-runners)
  • L33 in content/docs/insights/self-hosted.md "There is a documented process for setting up Discovery scans using customer-managed workflow runners." → ✅ verified (evidence: The page itself contains a "### Setting up Discovery scans" section with a documented step-by-step process referencing customer-managed workflow runner pools: "1. Set up a customer-managed workflow runner pool ... 2. Navigate to Management…; source: repo:content/docs/insights/self-hosted.md)
  • L35 in content/docs/insights/self-hosted.md "Setting up a customer-managed workflow runner pool is documented at /docs/deployments/guides/customer-managed-workflow-runners/#using-customer-managed-workflow…" → ✅ verified (evidence: content/docs/deployments/guides/customer-managed-workflow-runners.md contains the heading "## Using customer-managed workflow runners", which maps to the anchor #using-customer-managed-workflow-runners referenced in the claim, confirming t…; source: repo:content/docs/deployments/guides/customer-managed-workflow-runners.md)
  • L53 in content/docs/insights/self-hosted.md "Workflow runners provide an enabled_workflow_types configuration option in pulumi-workflow-agent.yaml that can be used to restrict which workflow types a r…" → ✅ verified (evidence: Sibling docs confirm this exact API surface: customer-managed-runners.md shows enabled_workflow_types: in pulumi-workflow-agent.yaml, and customer-managed-workflow-runners.md states "You can restrict which workflow types a workflow run…; source: gh search code --owner pulumi "enabled_workflow_types" (content/docs/deployments/concepts/customer-managed-runners.md, content/docs/deployments/guides/customer-managed-workflow-runners.md))
  • L79 in content/docs/integrations/clouds/aws/_index.md "For AWS, Insights connects AWS accounts (including AWS Partitions) to inventory existing resources, search across accounts, and export data. See [Add an AWS ac…" → ✅ verified (evidence: The target page content/docs/insights/discovery/get-started/create-accounts.md exists and walks through connecting an AWS cloud account, including reviewing "the partition the account belongs to and the regions you want scanned" during the…; source: repo:content/docs/insights/discovery/get-started/create-accounts.md)
  • L70 in content/docs/integrations/clouds/azure/_index.md "For Azure, Insights connects subscriptions to inventory existing resources, search across subscriptions, and export data. See [Add an Azure account](/docs/insi…" → ✅ verified (evidence: The linked page content/docs/insights/discovery/get-started/create-accounts.md exists at that URL path and is exactly a step-by-step guide: "With the prerequisites in place, let's connect your first cloud account and kick off a discovery s…; source: gh api repos/pulumi/docs/contents/content/docs/insights/discovery/get-started/create-accounts.md)
  • L65 in content/docs/integrations/clouds/gcp/_index.md "For Google Cloud, Insights connects projects to inventory existing resources, search across projects, and export data. See [Add a Google Cloud account](/docs/i…" → ✅ verified (evidence: The file content/docs/insights/discovery/get-started/create-accounts.md exists at that exact path/URL, titled "Create an Insights Account," and states "Azure and Google Cloud follow the same flow with their own browser-based sign-in," conf…; source: gh api repos/pulumi/docs/contents/content/docs/insights/discovery/get-started/create-accounts.md)
  • L35-36 in content/tutorials/eval-compliance-terraform/index.md "An ESC environment and AWS credentials must be created and configured, as documented at /docs/insights/discovery/accounts/#configure-esc-credentials." → ✅ verified (evidence: The linked page content/docs/insights/discovery/accounts.md contains a "## Configure ESC credentials" section (line 93) describing AWS/Azure ESC environment setup, matching the anchor #configure-esc-credentials cited in the claim; other do…; source: repo:content/docs/insights/discovery/accounts.md)
  • L124 in content/tutorials/eval-compliance-terraform/index.md "Pulumi Insights account scanning functionality has been renamed to 'Discovery' scanning." → ✅ verified (evidence: Current Pulumi docs (content/docs/insights/discovery/_index.md) confirm: "Pulumi's Discovery feature enables organizations to gain complete visibility into their cloud infrastructure by scanning cloud provider accounts..." with URLs living…; source: repo:content/docs/insights/discovery/_index.md)
  • L124 in content/tutorials/eval-compliance-terraform/index.md "The Pulumi Console's Accounts page allows a user to navigate to and click on their cloud account to run a Discovery scan." → 🤷 unverifiable (evidence: The cited URL is a sign-in page (body just renders 'Pulumi Cloud' shell with no content), which requires authentication and cannot confirm or deny details about the Accounts page or Discovery scan workflow.; source: https://app.pulumi.com/signin)
  • L126 in content/tutorials/eval-compliance-terraform/index.md "The video demonstrates navigating to the cloud accounts page." → ✅ verified (evidence: The doc contains the shortcode {{< video title="Navigating to the cloud accounts page" src="/tutorials/eval-compliance-terraform/assets/insights-nav-to-accounts.mp4" ... >}} immediately following text instructing the reader to "navigate…; source: repo:content/tutorials/eval-compliance-terraform/index.md (line 126))
  • L128 in content/tutorials/eval-compliance-terraform/index.md "After clicking the Actions dropdown, selecting the Scan radio button, and clicking Scan, a status message stating 'Scan started a few seconds ago' appears once…" → 🤝 matches (evidence: Line 128 of the source file states verbatim: "Once there, click on the Actions dropdown and select the Scan radio button, then click Scan. You will see a status message that says "Scan started a few seconds ago" once the scan h…; source: repo:content/tutorials/eval-compliance-terraform/index.md)
  • L132 in content/tutorials/eval-compliance-terraform/index.md "To check on the status of the scan, users must navigate to the individual sub-accounts of their cloud account and click the Scans tab." → ✅ verified (evidence: Line 132 of the file reads verbatim: "To check on the status of the scan, you will need to navigate to the individual sub-accounts of your cloud account and click the Scans tab." This matches the claim exactly (minor phrasing paraphras…; source: repo:content/tutorials/eval-compliance-terraform/index.md)
  • L144 in content/tutorials/eval-compliance-terraform/index.md "Users can learn more about querying and filtering resources by reviewing the 'Using Resource Explorer' documentation at /docs/insights/discovery/get-started/us…" → ✅ verified (evidence: The page exists at content/docs/insights/discovery/get-started/using-resource-explorer.md with title "Using Resource Explorer", which builds to the URL /docs/insights/discovery/get-started/using-resource-explorer/ cited in the claim (the o…; source: repo:content/docs/insights/discovery/get-started/using-resource-explorer.md)
  • L201 in content/tutorials/eval-compliance-terraform/index.md "A policy pack can be added to a cloud account (this section's procedure/heading describes that capability)." → ✅ verified (evidence: The section "Add policy pack to a cloud account" describes creating a Policy Group associating the published policy pack with a cloud account: "you'll need to create a Policy Group that associates your cloud account with a policy pack... a…; source: repo:content/tutorials/eval-compliance-terraform/index.md)
  • L203 in content/tutorials/eval-compliance-terraform/index.md "After publishing a policy pack, a user needs to create a Policy Group that associates their cloud account with a policy pack." → ✅ verified (evidence: The same document states: "With your policy pack published, you'll need to create a Policy Group that associates your cloud account with a policy pack," and proceeds to walk through creating the policy group, adding the policy pack, and ad…; source: repo:content/tutorials/eval-compliance-terraform/index.md)
  • L203 in content/tutorials/eval-compliance-terraform/index.md "In the Pulumi Cloud console, the Policies option for creating a Policy Group is found under the Pulumi Insights section." → ✅ verified (evidence: The tutorial itself states: "In the Pulumi Cloud console, navigate to Policies under the Pulumi Insights section," and this is corroborated by pulumi/docs content (e.g., content/docs/insights/policy/_index.md and content/docs/insig…; source: repo:content/tutorials/eval-compliance-terraform/index.md (L203); pulumi/docs:content/docs/insights/_index.md)
  • L215 in content/tutorials/eval-compliance-terraform/index.md "Users must add their cloud account to the policy group by clicking Add accounts on the Policy Group configuration page and typing the name of the account to in…" → 🤝 matches (evidence: The claim is a paraphrase of the file's own text at line 215: "click Add accounts, and type the name of the account you want to include for policy evaluation (e.g. pulumi-tutorials-insights/us-west-2). Then click **Add account to polic…; source: repo:content/tutorials/eval-compliance-terraform/index.md)
  • L130 in content/what-is/what-is-cloud-misconfiguration.md "Together, Pulumi Discovery and governance let a team prevent new misconfigurations at deploy time and continuously audit for e…" → ✅ verified (evidence: The page content/product/insights-governance.md exists in pulumi/docs and is linked consistently across sibling pages (e.g., what-is-policy-as-code.md: "The combination of policy as code enforcement with Insights-based governance..."), h…; source: gh search code --repo pulumi/docs insights-governance)
  • L170 in content/what-is/what-is-cloud-misconfiguration.md "* Discovery and governance" → ✅ verified (evidence: The page content/product/insights-governance.md exists in pulumi/docs and is linked from data/footer.yml, data/header_nav.yaml, and numerous other content pages at the exact path /product/insights-governance/, confirming the link t…; source: gh search code --owner pulumi "insights-governance" -R pulumi/docs)
  • L171 in content/what-is/what-is-cloud-misconfiguration.md "* Pulumi Discovery" → ✅ verified (evidence: content/docs/insights/discovery/_index.md exists with title "Discovery" and describes Pulumi's Discovery feature, matching the linked path /docs/insights/discovery/.; source: repo:content/docs/insights/discovery/_index.md)
  • L209 in content/what-is/what-is-policy-as-code.md "* Discovery and governance" → ✅ verified (evidence: The page content/product/insights-governance.md exists in pulumi/docs and is linked from many other pages (data/footer.yml, data/header_nav.yaml, content/_index.md, and sibling what-is pages like what-is-cloud-misconfiguration.md), confirm…; source: gh search code --owner pulumi "insights-governance" (pulumi/docs:content/product/insights-governance.md))
  • L1 in content/docs/_index.md "frontmatter alias /docs/reference/ collides with content/docs/reference/_index.md" → 🚩 flagged (frontmatter: alias-collision)
  • L1 in content/docs/insights/policy/_index.md "frontmatter alias /docs/iac/packages-and-automation/crossguard/ collides with content/docs/support/faq/policies.md" → 🚩 flagged (frontmatter: alias-collision)

@github-actions

Copy link
Copy Markdown
Contributor

🚨 Outstanding in this PR

No outstanding blockers. Every contradiction flag was triaged as an artifact of comparing new wording against the not-yet-updated live site (see 📋 Triaged verifier findings), and the substantive link/alias issues are pre-existing (see 💡 Pre-existing).

⚠️ Low-confidence

Review each and resolve as appropriate — these don't block the PR.

  • [L98] content/docs/administration/access-identity/rbac/scopes/org-settings.md"| policy_results:create | Create policy evaluation results for a cloud account.

    Granted by default roles: Admin |"
    — verdict: unverifiable; evidence: Search results confirm the org-settings RBAC scopes page exists and covers organization-level operations including policy evaluations/insights accounts, but the specific table row for policy_results:create and its default-role grant to …; source: WebSearch ran query "Pulumi RBAC scopes policy_results:create"; top results didn't show the specific scope table row. This PR only renames the row's prose ("insights account" → "cloud account"); the scope's existence is confirmed in the repo table, and the Admindefault-role grant couldn't be corroborated externally. Not a blocker for this rename — **author:** confirm theAdmindefault-role grant onpolicy_results:create` is still accurate if you have product-side visibility.

  • [L51] content/docs/insights/discovery/accounts.md"In the future, the account hierarchies feature will be expanded to support creating custom hierarchies, providing more flexibility for structuring accounts, su…" — verdict: unverifiable; evidence: This is a forward-looking roadmap statement about Pulumi Insights' own product plans (self-contained in the same doc, consistent with the adjacent line noting Kubernetes cluster child-account support "will soon" be added). It's a first-par…; source: repo:content/docs/insights/discovery/accounts.md; intuition: Roadmap/future-feature claims in first-party docs are typically not falsifiable until shipped; treat as authorial intent. This is a forward-looking roadmap line, unchanged by the rename beyond terminology — not a blocker. Author: confirm the "custom hierarchies" roadmap statement is still accurate.

  • [L4] content/docs/insights/discovery/get-started/begin.md"The page heading (h1) is 'Before You Begin', with no product name prefix, unlike the prior version which used 'Pulumi Insights: Before You Begin'." — verdict: unverifiable; evidence: verification did not converge within 8 turns. This is a claim about the heading text only, which is part of the intended rename; not a blocker. No author action needed unless the h1 was meant to keep a product prefix.

  • [L124] content/tutorials/eval-compliance-terraform/index.md"The Pulumi Console's Accounts page allows a user to navigate to and click on their cloud account to run a Discovery scan." — verdict: unverifiable; evidence: The cited URL is a sign-in page (body just renders 'Pulumi Cloud' shell with no content), which requires authentication and cannot confirm or deny details about the Accounts page or Discovery scan workflow.; source: https://app.pulumi.com/signin. The cited URL requires authentication, so the Console workflow couldn't be checked externally; this describes existing product UI unchanged by the rename. Not a blocker.

Style findings

Found by pattern-based linting; Findings may be false positives.

Click each filename to expand.

content/docs/administration/access-identity/rbac/_index.md (2 issues: 2 wordiness)
  • line 61: [style] wordiness — 'in addition' is too wordy.
  • line 61: [style] wordiness — 'all of' is too wordy.
content/docs/administration/access-identity/rbac/scopes/insights-accounts.md (1 issues: 1 wordiness)
  • line 44: [style] wordiness — 'it was' is too wordy.
content/docs/deployments/concepts/customer-managed-runners.md (1 issues: 1 substitution)
  • line 34: [style] substitution — Use 'select' instead of 'click' (STYLE-GUIDE.md).
content/docs/deployments/guides/customer-managed-workflow-runners.md (1 issues: 1 wordiness)
  • line 64: [style] wordiness — 'designate' is too wordy.
content/docs/insights/discovery/accounts.md (2 issues: 2 wordiness)
  • line 51: [style] wordiness — 'in the case of' is too wordy.
  • line 63: [style] wordiness — 'it is' is too wordy.
content/docs/insights/discovery/connect-cloud-accounts.md (2 issues: 1 filler, 1 wordiness)
  • line 172: [style] filler — Don't start a sentence with 'There is'.
  • line 192: [style] wordiness — 'Alternatively' is too wordy.
content/docs/insights/self-hosted.md (1 issues: 1 heading capitalization)
  • line 33: [style] heading capitalization — Heading 'Setting up Discovery scans' should use sentence case (capitalize only the first word and proper nouns).
content/tutorials/eval-compliance-terraform/index.md (5 issues: 4 substitution, 1 nomenclature)
  • line 124: [style] nomenclature — Use Pulumi's canonical spelling: 'Pulumi Cloud console' instead of 'Pulumi Console' (STYLE-GUIDE.md §Product Names).
  • line 124: [style] substitution — Use 'select' instead of 'click' (STYLE-GUIDE.md).
  • line 132: [style] substitution — Use 'select' instead of 'click' (STYLE-GUIDE.md).
  • line 215: [style] substitution — Use 'select' instead of 'click' (STYLE-GUIDE.md).
  • line 215: [style] substitution — Use 'select' instead of 'click' (STYLE-GUIDE.md).

📋 Triaged verifier findings

I double-checked these and realized they weren't real findings — click to expand
  • [L4-5] content/docs/administration/access-identity/rbac/scopes/insights-accounts.md"The page title and heading for this RBAC scopes page is 'RBAC Scopes: Cloud Accounts'."Spurious: the ❌ contradiction was raised by comparing against the live production page, which still reads "Insights accounts" because this PR hasn't merged. The PR's own file now sets title/h1/menu name to "Cloud Accounts" (verified against the repo), which is the intended rename.

  • [L84] content/docs/administration/access-identity/rbac/scopes/org-settings.md"| insights_account:create | Create a new cloud account. …"Spurious: the ⚔️ mismatch flags the scope literal insights_account:create still carrying an "insights account" description elsewhere, but that divergence is deliberate and consistent across this PR — the API scope names (insights_account:*) are intentionally retained while only the human-readable descriptions are renamed to "cloud account". The sibling insights-accounts.md and teams.md apply the same pattern.

  • [L2-3] content/docs/insights/_index.md"The Pulumi product/feature area formerly named 'Insights & Governance' is now named 'Discovery & Governance'."Spurious: contradicted only against the live pre-merge site. The section rename to "Discovery & Governance" is an intentional, consistent part of this PR — content/_index.md and content/docs/_index.md make the same "Insights & governance" → "Discovery & governance" change in their diffs.

  • [L3] content/docs/insights/discovery/data-export.md"This documentation page is titled 'Data Export | Discovery & Governance' …"Spurious: same section rename as above; the live breadcrumb still shows "Insights & Governance" because the rename hasn't shipped yet.

  • [L5] content/docs/insights/discovery/get-started/begin.md"This page provides an overview on how to get started with cloud accounts in Pulumi."Spurious: contradicted against the live page's old wording ("Pulumi Insights Accounts"); the "cloud accounts" wording is exactly what this PR changes it to.

  • [L32] content/docs/insights/discovery/get-started/begin.md"The Discovery setup wizard generates ESC environments for connecting cloud accounts following the same best practices as the manual OIDC configuration guides…"Spurious: the live page describes the older manual flow, but the PR's own file now states the wizard generates these environments "following the same best practices as the manual OIDC guides" (verified against the repo). The contradiction reflects the stale live page, not the new content.

  • [L3] content/docs/insights/self-hosted.md"The product previously referred to as Pulumi Insights is now referred to as Discovery in this documentation's title and meta description."Spurious: the extracted claim overstated the rename. The repo file correctly keeps the title "Self-hosted Insights"; only the umbrella section label and the "Discovery scans" feature reference change. The page is right as written.

💡 Pre-existing issues in touched files (optional)

  • [L20-26] content/docs/insights/discovery/data-export.md — the "Programmatically … Pulumi Cloud REST API" link points at /docs/reference/cloud-rest-api/cloud-rest-api/, a path that doesn't exist (the REST API reference is generated per-tag; there's no cloud-rest-api/cloud-rest-api/ page). Pre-existing: the link sits on a context line this PR doesn't modify — the diff only changes an adjacent image alt text. Worth a follow-up fix (likely /docs/reference/cloud-rest-api/#data-export), but it's not introduced by this rename.

  • [L1] content/docs/_index.md — the frontmatter alias /docs/reference/ collides with the URL of content/docs/reference/_index.md. Pre-existing: the alias is untouched by this PR (the only change to this file is the "Insights & Governance" → "Discovery & Governance" heading text). Not introduced here.

  • [L1] content/docs/insights/policy/_index.md — the frontmatter alias /docs/iac/packages-and-automation/crossguard/ collides with content/docs/support/faq/policies.md. Pre-existing: the alias list is untouched by this PR (this file's diff only renames terminology in title_tag and body prose). Not introduced here.

✅ Resolved since last review

No items resolved since the last review.

📜 Review history

  • 2026-07-28T00:03:04Z — Terminology rename (Insights Discovery→Discovery, Insights Accounts→Cloud Accounts, section→Discovery & Governance); no blockers — all contradiction flags were live-vs-pre-merge artifacts, plus 3 pre-existing link/alias issues on untouched lines. (3b54cfa)

Need a re-review? Want to dispute a finding? Mention @claude and include #update-review.
(For ad-hoc questions or fixes, just @claude — no hashtag.)

@github-actions github-actions Bot added review:no-blockers Claude review completed cleanly; outstanding is empty and removed review:in-progress Claude review is currently running labels Jul 28, 2026
@CamSoper
CamSoper requested a review from tatcoo-pulumi July 30, 2026 22:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

domain:docs PR touches technical docs domain:infra PR touches workflows, scripts, infra, Makefile, or build config domain:mixed PR touches more than one domain domain:website PR touches marketing, pricing, legal, or competitive landing pages review:no-blockers Claude review completed cleanly; outstanding is empty

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants