Product rollout observation

# Product rollout observation

## Goal

Reconstruct what authorized humans actually executed from an approved rollout plan: which release reached which eligible population, through which stage, when, under whose recorded approval, with what deviations, incidents, stop-condition results, and rollback or containment actions.

A rollout plan is not a release. A release-readiness decision is not exposure. A configured flag is not proof that an eligible user received the behavior, and an absence of incident records is not proof that the release was healthy.

Run this prompt only after authorized humans may have executed at least one rollout stage. This is read-only observation. Do not deploy, merge, push, publish, change feature flags, run or reverse migrations, alter configuration or data, execute a rollback, contact users, query production, or connect to external systems.

Inspect only authorized execution evidence already available in the workspace. Complete the observation autonomously. Do not stop to ask clarifying questions. If no stage can be verified, choose `NO VERIFIED RELEASE` rather than converting the plan into history.

## Inputs

Locate and read:

* all applicable `AGENTS.md` files
* `docs/product/release-readiness.md`, `docs/product/release-readiness.yaml`, and `docs/product/release-readiness-changelog.md`
* `docs/product/rollout-plan.md`, `docs/product/rollout-plan.yaml`, and `docs/product/rollout-plan-changelog.md`
* the accepted product contract, delivery, acceptance-verification, and release-candidate records referenced by those artifacts
* authorized deployment, build, release, feature-flag, configuration, migration, and audit exports already present in the workspace
* authorized approval, change-management, operator, incident, alert, rollback, recovery, and remediation records already present
* authorized telemetry, event-definition, support, reliability, performance, cost, and data-quality extracts already present
* contractual, security, privacy, consent, data-processing, retention, deletion, residency, and incident-notice requirements
* any existing `docs/product/rollout-observation.md`, `docs/product/rollout-observation.yaml`, and `docs/product/rollout-observation-changelog.md`

Do not fetch missing evidence from production, dashboards, feature-flag services, cloud consoles, analytics tools, support systems, or user accounts. Record the missing source as `UNKNOWN` and identify the authorized human owner who could supply an export.

## Inherited decision gate

The governing release-readiness decision must be exactly `GO` or `GO NARROWLY`. The governing rollout-plan decision must be exactly `ROLLOUT` or `ROLLOUT NARROWLY`.

Verify exact versions, release identifier, candidate identifier, accepted limits, planned stages, and changelog order. Do not silently use a later plan to legitimize an earlier action.

If either inherited decision is absent, inconsistent, superseded by a hold or rollback, or outside its stated scope:

* choose `NO VERIFIED RELEASE` when no execution can be established
* choose `REVISIT ROLLOUT` when execution evidence exists despite an invalid, conflicting, expired, or exceeded gate

An inherited `GO NARROWLY` or `ROLLOUT NARROWLY` limits what can count as authorized. It is not equivalent to unrestricted release approval.

## Evidence standard

Label every material claim with exactly one shared product-evidence label:

* `OBSERVED`: directly supported by an identified, authorized execution source
* `DERIVED`: calculated or logically produced from identified `OBSERVED` inputs, with the method shown
* `ASSUMED`: an explicit interpretation or planning premise not established by execution evidence
* `UNKNOWN`: absent, inaccessible, immature, conflicting, unauthorized for this use, or not safely inferable

Do not relabel a planned value `OBSERVED` because it is plausible. For every `DERIVED` value show sources, inputs, calculation, timestamps, window, exclusions, and limitations.

Record exact timestamps with timezone when present. Do not invent precision. If only a date or sequence is supported, preserve that granularity and label narrower timing `UNKNOWN`.

## Step 1: Establish source authority and provenance

Build a source ledger before reconstructing execution. For each source record:

* source ID, owner, location, producing system, and capture or export time
* whether it is a plan, operator assertion, immutable audit record, snapshot, derived report, or telemetry extract
* authorized purpose, time coverage, timezone, and release, environment, cohort, or identity keys
* retention, deletion, access, residency, and personal or sensitive-data restrictions
* known gaps, mutable fields, clock drift, and data-quality limitations
* inclusion or exclusion decision with reason

Prefer immutable execution and audit records over recollection. An operator note may establish context; it does not independently prove exposure when the underlying action record is absent.

Minimize copied data. Do not place names, emails, account secrets, message content, raw identifiers, or sensitive traits in the artifacts. Use stable de-identified stage, cohort, and incident IDs. Suppress small cells that could identify a person.

## Step 2: Freeze the planned basis

Extract the plan as it existed immediately before the first observed action:

* release-readiness and rollout-plan versions and decisions
* release candidate, commit, build, artifact, schema, migration, environment, and exposure mechanism
* planned stages, eligibility, exclusions, and maximum exposure
* required approvals and entry, promotion, hold, and stop gates
* observation windows and cohort-maturity rules
* rollback, recovery, privacy, security, accessibility, support, and legal conditions

Mark every field as planned in the comparison ledger even when inherited from an approved artifact. Approval is observed approval of a plan, not observed execution of its contents.

If the pre-action plan version cannot be reconstructed, preserve the ambiguity. Do not use a post-action edit as evidence that the action was pre-approved.

## Step 3: Reconstruct the actual stage timeline

Build a chronological ledger with one row per independently evidenced action or state transition.

For each row record:

* stable observation ID, matched planned stage ID, and actual action or state
* release, candidate, build, flag, configuration, migration, environment, and exposure identifiers
* start and end timestamp with timezone and source precision
* recorded actor and approver roles, approval record, and whether approval preceded the action
* eligibility rule, observed exposure boundary, and raw count when available
* monitoring record, gate result, and subsequent action
* source IDs and evidence label

Distinguish deployment, technical availability, entitlement, flag eligibility, actual exposure opportunity, product use, and outcome. Do not collapse them into “released.”

When sources conflict, keep both observations, identify which field conflicts, and leave the reconciled value `UNKNOWN` unless an authoritative source and rule resolve it.

## Step 4: Compare planned and observed execution

For every planned stage and material field, report:

* planned value, source version, and observed value or `UNKNOWN`
* variance and whether it stayed inside the approved boundary
* recorded approval for the variance
* risk or analytic consequence
* required human follow-up

Include stages that were planned but not observed, stages observed outside the plan, skipped gates, reordered actions, early promotion, prolonged exposure, changed eligibility, expanded blast radius, different release identity, and missing reviews.

An unobserved planned stage has an observed value of `null` with evidence `UNKNOWN`; it is not failed or complete. An observed unplanned action remains evidence even when it was unauthorized; do not omit it to preserve the plan narrative.

## Step 5: Reconstruct exposure and cohort integrity

Where authorized evidence permits, report the flow in raw counts:

```text
planned eligible → actual eligible → technically exposed → opportunity to encounter
```

For each count state denominator, identity unit, window, source, exclusions, and evidence label. Identify:

* internal, test, bot, duplicate, corrupted, ineligible, or excluded records
* eligible units not exposed and crossover between stages
* staggered, interrupted, or partial exposure and ambiguous identity joins
* cohort contamination from other releases or interventions
* small cohorts that cannot be safely reported

Do not infer actual exposure from a percentage configured in a flag service without an observed eligible denominator and assignment record. Do not reuse protected or sensitive attributes to reconstruct cohorts unless the use is lawful, necessary, documented, and human-reviewed.

## Step 6: Observe gates, stop conditions, and approvals

For each planned entry, promotion, hold, and stop condition record:

* registered definition, threshold, review time, and owner
* authorized existing evidence available at that time and observed result, `null`, or `UNKNOWN`
* recorded human review, decision, and timestamp
* action that followed
* deviations and limitations

Do not claim a gate passed because rollout continued. Do not recompute a historical decision from evidence that became available later without labeling it retrospective.

Treat security, privacy, data integrity, billing, accessibility, safety, and contractual stop conditions individually. Never average a severe event into an overall healthy rate.

## Step 7: Record incidents, containment, and rollback actions

Create one row per observed alert, incident, stop, containment, rollback, forward fix, recovery, or remediation action.

Record:

* stable incident or action ID with detected and recorded timestamps
* affected release, stage, cohort, workflow, and data boundary
* observed symptom, recorded severity, and implicated stop condition
* decision owner, approval evidence, and action actually taken
* code, flag, configuration, migration, data, or external side effects
* verification of containment, reversal, recovery, or unresolved impact
* required privacy, security, contractual, or user-notice review
* sources, evidence label, and unknowns

An alert is not automatically an incident. A rollback command is not proof that all effects were reversed. Distinguish code reversal, disabled exposure, schema state, data repair, customer remediation, and recovery verification.

If an incident or rollback is mentioned without authorized evidence, record the claim as `ASSUMED` or `UNKNOWN`; do not create a fictional action history.

## Step 8: Desk-test the observation

Verify:

1. Both inherited decisions and exact artifact versions were checked.
2. Planned fields and observed fields remain visibly separate.
3. At least one executed stage has evidence before any decision calls the product released.
4. Release identity, timestamps, approvals, exposure, deviations, and gate reviews cite sources or remain unknown.
5. Actual exposure is not inferred from deployment or flag configuration alone.
6. Incidents, stop conditions, and rollback effects are not hidden or averaged away.
7. Personal and sensitive data is minimized and protected, and no production query, deployment, flag change, migration, rollback, communication, or user contact occurred.

## Decision

Choose exactly one:

* `OBSERVED RELEASE`: authorized evidence verifies at least one executed rollout stage, its release identity, timing, approval, and exposure boundary; state only the verified scope
* `PARTIAL OBSERVATION`: execution evidence exists, but material stage, timing, approval, exposure, gate, deviation, incident, or rollback fields remain incomplete or conflicting
* `NO VERIFIED RELEASE`: no authorized existing evidence verifies that an approved rollout stage was executed
* `REVISIT ROLLOUT`: observed execution exceeded or conflicted with inherited gates, skipped a material control, triggered an unresolved stop condition, or cannot be reconciled safely with the approved release

This decision records evidence quality and rollout conformance. It does not authorize continuation, expansion, pause, or rollback.

Lead with:

“As of [evidence cutoff], release [identifier or unknown] has [N] planned stages and [N] observed executed stages, with verified exposure [raw count and boundary or unknown], [N] material deviations, [N] observed incidents, and decision [OBSERVED RELEASE / PARTIAL OBSERVATION / NO VERIFIED RELEASE / REVISIT ROLLOUT]. This analysis performed no production or user action.”

## Required artifacts

### 1. `docs/product/rollout-observation.md`

Lead statement, inherited gate audit, source ledger, frozen planned basis, actual stage timeline, planned-versus-observed comparison, exposure integrity, gate and approval results, incidents and rollback actions, limitations, desk test, decision, and handoff.

### 2. `docs/product/rollout-observation.yaml`

Include `version`, `status`, `as_of`, `evidence_cutoff`, `decision`, `release_readiness_version`, `release_readiness_decision`, `rollout_plan_version`, `rollout_plan_decision`, `release_id`, `candidate_id`, `planned_basis`, `observed_stages`, `actual_timeline`, `planned_vs_observed`, `exposure`, `approvals`, `gate_results`, `deviations`, `incidents`, `stop_conditions`, `rollback_actions`, `data_authority`, `privacy_and_legal`, `assumptions`, `unknowns`, and `sources`.

Use `null` for unknown values with an explanation. Use stable IDs and keep raw personal-level data out of YAML. Set `status: observed` only for the verified scope; otherwise use `status: partial`, `status: unverified`, or `status: revisit` to match the decision.

### 3. `docs/product/rollout-observation-changelog.md`

Append only. Record timestamp, version, evidence cutoff, inherited artifact versions, sources added, newly observed stages, corrected conflicts, deviations, incidents, rollback evidence, decision, and reason. Never overwrite an earlier observation or backdate approval.

## Closed-loop handoff

Reconcile verified release identity, actual stage, exposure boundary, timestamps, approvals, deviations, incident status, and applicable cohort limits back into the existing Product adoption enablement record without rewriting its pre-release plan. A planned or unverified intervention remains planned.

Pass the same verified facts, observation windows, contamination, and cohort-integrity limits to Product outcome measurement. Outcome analysis must not include units outside the observed exposure boundary or count observation time before actual exposure.

For `PARTIAL OBSERVATION`, downstream prompts may analyze only explicitly verified subsets and must inherit every unknown. For `NO VERIFIED RELEASE`, stop downstream adoption and outcome claims. For `REVISIT ROLLOUT`, return the discrepancy or unresolved stop condition to authorized release and rollout owners; do not perform their action.

Full-cycle GTM may receive verified current availability and support implications within its own authorization. It may not claim a release, adoption, or outcome beyond this evidence. Later product-cycle decisions must preserve this rollout history when expanding, iterating, maintaining, rolling back, retiring, or restarting discovery.

## Boundaries

* Inspect only authorized existing evidence in the workspace.
* Do not deploy, merge, push, change flags or configuration, run migrations, alter data, execute rollback, publish, message, or contact users.
* Do not query production, dashboards, cloud consoles, analytics services, support tools, or user accounts.
* Do not invent releases, stages, actors, approvals, exposure, timestamps, telemetry, deviations, incidents, stop results, rollback actions, recovery, or user behavior.
* Do not turn planned values, configured percentages, or operator expectations into observed execution.
* Do not reuse customer, support, audit, or personal data outside its authorized purpose.
* Do not expose personal information, secrets, sensitive traits, or identifying small cohorts.
* Preserve uncertainty, historical sequence, and human action authority.

## Done when

* Inherited `GO` or `GO NARROWLY` and `ROLLOUT` or `ROLLOUT NARROWLY` gates are verified against exact versions.
* Planned and observed stages, exposure, timestamps, approvals, deviations, incidents, stop conditions, and rollback actions are separately documented.
* Every material claim uses `OBSERVED`, `DERIVED`, `ASSUMED`, or `UNKNOWN`.
* Data authority, privacy, legal, cohort-integrity, and small-cell limits are explicit.
* The Markdown, YAML, and append-only changelog agree.
* The decision uses one allowed value and describes only the verified scope.
* Adoption enablement and outcome measurement receive a truthful, bounded execution record.