ops(use-cases): measure the pilot and decide whether to expand

## Context

The /use-cases/ family is a measured product-content experiment, not authorization for an ongoing page queue. The hub and three child pages must earn expansion through valid evidence: crawl/index health, distinct query intent, useful engagement, credible product handoffs, and a maintainable canonical/content contract.

This ticket closes the pilot loop. It must preserve unavailable data as unavailable, compare the new URLs with the prior canonical/editorial surfaces, and make an explicit expand, hold, consolidate, or reverse decision. Publishing pages is not success by itself.

## What to do

After #6849, #6850, and #6851 are live, record the production release date and deployed revision, verify that every URL is technically eligible for indexing, and collect the first valid observation window using the existing SEO/AI visibility and content-to-product measurement contracts.

Measure these landing pages separately:

- /use-cases/
- /use-cases/monitor-country-risk/
- /use-cases/verify-breaking-news/
- /use-cases/monitor-supply-chain-disruptions/

Also retain comparison rows for any previous article URL that was redirected, retained as supporting editorial content, or selected as the prior canonical surface.

## Measurement contract

### Technical and indexation health

- Record production status, final URL, canonical target, robots eligibility, sitemap ownership, crawlable inbound links, structured-data validity, and whether the response is the expected static page rather than an SPA fallback.
- Record Google Search Console URL/index status where supported, discovered/crawled/indexed state, and any canonical selected by Google that differs from the declared canonical.
- Check redirect chains and internal references for migrated article URLs.
- Keep platform-reported unavailable, pending, or insufficient-data states distinct from zero.

### Search demand and intent

- Use Query × Page exports, not only site-wide query totals.
- Report impressions, clicks, CTR, and average position per landing page for the valid trailing window and any supported comparison window.
- Separate branded navigation from non-brand task intent so homepage demand does not make the pilot look successful.
- Group observed non-brand queries by the actual user job and identify whether each child page attracts a distinct intent.
- Check whether use-case pages and retained blog/reference pages compete for the same queries or are clustered under a different canonical.
- Do not expose raw credentials, property identifiers, personal data, or unrestricted raw exports in the repository.

### Engagement and product handoffs

- Reconcile bounded landing-page sessions/views with the use-case CTA events established by #6849.
- Report primary dashboard launches and the Pro, API, or MCP handoffs that each page actually exposes.
- Where privacy-safe aggregates exist, report downstream pricing views, sign-ups, activations, paid conversions, API actions, and MCP actions without joining or publishing user-level data.
- Validate that inbound campaign attribution survives each handoff and that use-case events are not misclassified as blog traffic.
- Treat missing analytics or commerce aggregates as unavailable, not zero.

### Content and maintenance quality

- Confirm that each child page still has a distinct workflow, current product evidence, working exact-state links, accurate entitlement wording, and current provenance/freshness limitations.
- Record broken links, stale screenshots, unsupported claims, duplicated sections, or data-dependent copy that cannot be maintained safely.
- Compare maintenance cost and drift risk with keeping the workflow inside the existing blog or reference corpus.

## Decision rubric

End the ticket with exactly one pilot decision and the evidence that supports it:

- Expand — the pages are indexable, at least two child pages attract distinct non-brand task intent, the product handoffs are valid and used, canonical ownership is stable, and the content can be maintained. Expansion still requires separately approved, evidence-backed page tickets.
- Hold — the implementation is healthy but the observation window or demand volume is insufficient. State the next observation date and do not publish more pages.
- Consolidate — one or more pages overlap each other or an existing article/reference page. Name the surviving canonical URL and the redirect/internal-link changes required.
- Reverse — the family creates persistent duplication/canonical problems, broken product handoffs, misleading claims, or maintenance cost that exceeds its value. Retain a hub that links proven canonical pages only, or remove the family with redirects.

The report must not claim that the pilot caused ranking, traffic, citation, signup, or revenue changes. One observation cycle can support a bounded product/content decision, not causal attribution.

## Acceptance criteria

- [ ] The production release date and deployed revision for the completed pilot are recorded before the observation window starts.
- [ ] All four pilot URLs have verified status, canonical, robots, sitemap, crawlable-link, static-response, and supported structured-data results.
- [ ] Redirected or retained predecessor article URLs have verified redirect/canonical and internal-link behavior.
- [ ] A valid trailing 28-day Query × Page view is reported after the pages have been live for that period, or the ticket records why a valid window is unavailable and returns Hold rather than inventing a result.
- [ ] Each page has impressions, clicks, CTR, average position, index status, branded/non-brand split, and observed task-intent groups where Search Console supports them.
- [ ] The analysis identifies distinct intent, cannibalization, or Google-selected canonical clustering for every child page.
- [ ] Landing-page engagement and rendered Dashboard/Pro/API/MCP handoffs reconcile to bounded events; unavailable downstream aggregates remain null with reasons.
- [ ] Inbound campaign preservation and separation from blog attribution are verified in production.
- [ ] Content/product maintenance checks cover stale evidence, broken exact-state links, unsupported claims, duplicate material, entitlement wording, and source/freshness limitations.
- [ ] A dated, sanitized scorecard is stored using the repository's existing SEO/AI visibility reporting convention; credentials, raw restricted exports, prompts, and user-level data stay outside the repository.
- [ ] The scorecard compares the pilot against relevant prior canonical/editorial pages without presenting the comparison as causal uplift.
- [ ] The issue ends with one explicit Expand, Hold, Consolidate, or Reverse decision and a page-by-page rationale.
- [ ] Expansion, if selected, names only evidence-supported user jobs; it does not create a bulk queue or fixed page quota.

## Verification

- Re-run production status, canonical, robots, sitemap, structured-data, internal-link, redirect, and exact-product-state checks at the end of the observation window.
- Reproduce every aggregate in the sanitized scorecard from a documented query or export transformation.
- Reconcile site-wide totals with page-family totals and explain scope differences rather than forcing them to match.
- Have a second reviewer verify the decision against the source aggregates and the stated rubric.

## Non-goals

- Publishing additional use-case pages.
- Changing the search query panel or success criteria after results are visible to make the pilot pass.
- Scraping unsupported search surfaces or committing credentials/raw restricted exports.
- Claiming causal SEO, AI-citation, engagement, signup, or revenue uplift.
- Treating unavailable metrics as zero or retrying/reconstructing missing historical observations.

## Blocked by

- #6850 — the breaking-news verification page must be live.
- #6851 — the supply-chain disruption page must be live.

The hub and country-risk page are transitively required through #6849.

Start with the production verification checks and the existing SEO/AI visibility and content-to-product measurement contracts after #6849, #6850, and #6851 are live. Check the four pilot URLs and predecessor article URLs, then collect the supported trailing 28-day Query × Page and handoff aggregates. Done means a dated sanitized scorecard, a second-reviewer check, and exactly one Expand, Hold, Consolidate, or Reverse decision with page-level evidence.

Written by the indexing model from the issue text.