Observational opportunity ranking

# Observational opportunity ranking

## Goal

Rank bounded problem patterns for product-feedback review using observational evidence strength, product continuity, consequence, counterevidence, and learning value—without treating the ranking as roadmap authorization.

This is the final no-contact intelligence decision before the shared Product feedback prompt. It nominates evidence packages, not features. Downstream product prioritization still decides whether any opportunity deserves a product cycle.

Do not browse, collect, contact, modify code, create a roadmap, or prescribe implementation.

## Required prior artifacts

Read:

* `docs/product-intelligence/product-job-baseline.*`
* `docs/product-intelligence/research-policy.*`
* `docs/product-intelligence/evidence-ledger.*`
* `docs/product-intelligence/problem-patterns.*`
* `docs/product-intelligence/synthetic-stress-test.*`

Advance only from pattern decision `SYNTHESIZE` or `SYNTHESIZE NARROWLY` and stress-test decision `STRESS TEST` or `STRESS TEST NARROWLY`. Any inherited `HOLD` forces `HOLD`.

Consume only patterns that survived the stress-test boundary. Synthetic scenarios may narrow or challenge a pattern but may never add evidence strength.

Inspect prior `docs/product-intelligence/opportunity-ranking.*` artifacts and preserve stable candidate IDs, refusals, and history.

## Evidence contract

Use exactly `OBSERVED`, `DERIVED`, `ASSUMED`, and `UNKNOWN`.

Candidate problems are `DERIVED` from observational patterns. Synthetic challenges remain `ASSUMED`. Keep these distinct dimensions:

* observational directness and source independence
* consequence within the observed workflow
* current-product relevance and strategic continuity
* counterevidence and status-quo strength
* coverage, recency, and bias
* reversibility and learning value

Do not collapse the dimensions into an unexplained score. Unknown capacity, effort, prevalence, pricing, and economics remain unknown.

## Step 1: Form eligible candidates

Each candidate must contain:

* stable candidate and pattern IDs
* actor, situation, job, current behavior, failed outcome, and consequence
* current alternative or workaround
* observational evidence for and against
* independent source classes and bounded sample coverage
* product-boundary relationship
* inherited synthetic challenges and unresolved assumptions
* evidence that would reverse or reject the candidate

Keep solution requests and competitor features as context only. Reject a candidate that cannot be stated without prescribing a feature.

## Step 2: Apply eligibility gates

Test whether each candidate:

1. stays inside or explicitly adjacent to the current product job
2. has direct observational support beyond synthetic material
3. names a consequential workflow failure or desired outcome
4. retains meaningful counterevidence and source limitations
5. does not depend on personal-data exploitation, deception, unsafe use, or prohibited research
6. does not convert one platform, competitor move, or public statement into a market
7. can be handed to Product feedback without claiming prevalence, demand, or validation

Refuse integrity or safety failures. Hold evidence failures. Adjacent-product candidates cannot outrank current-product candidates without a separately documented strategic decision.

## Step 3: Compare candidates without fake precision

For each eligible candidate write the case for:

* nominate now for feedback review
* watch for more passive evidence
* refuse as off-boundary or structurally unsuitable

Compare the separate dimensions in the evidence contract and name at least one counterargument. If an existing registered ranking model is present, preserve its definitions and unknowns; do not create decimal theater.

Nominate no more than three candidates. Choose one lead candidate only when the evidence clearly supports the ordering. Otherwise preserve a bounded unordered set for downstream review.

## Step 4: Set the evidence ceiling

For every nomination state what the research supports and does not support. At minimum, it may support that:

* a bounded public pattern exists
* particular language, workflows, alternatives, or complaints were observed
* the pattern appears relevant to the current product boundary

It does not by itself support:

* market prevalence or total demand
* willingness to pay or price
* use of this product
* activation, retention, or realized outcomes
* causal claims or implementation choice

## Step 5: Write the Product feedback handoff

Create an inheritance block for the shared Product feedback prompt containing:

* decision and exact nomination boundary
* candidate and pattern IDs
* canonical observation and source IDs
* strongest support and counterevidence
* sampling and bias limits
* synthetic challenges, all marked `ASSUMED`
* explicit refusals and watch items
* questions Product feedback must decide

The handoff must be usable without reopening public sources.

## Decision

Choose exactly one:

* `NOMINATE`: one to three bounded candidates may enter Product feedback review
* `NOMINATE NARROWLY`: only named defects, actors, situations, or learning questions may enter
* `HOLD`: no candidate clears the evidence, fit, or integrity gates
* `REFUSE`: the leading pattern should not become product input

Lead with:

> As of [evidence cutoff], [N] observational candidates are nominated for Product feedback within [boundary], led by [candidate or unordered set], at evidence ceiling [ceiling], decision [NOMINATE / NOMINATE NARROWLY / HOLD / REFUSE].

## Required outputs

Create or update only:

### 1. `docs/product-intelligence/opportunity-ranking.md`

Decision, eligibility gates, candidate records, comparison, nominations, watch items, refusals, evidence ceilings, counterarguments, reversal conditions, Product feedback handoff, assumptions, unknowns, and sources.

### 2. `docs/product-intelligence/opportunity-ranking.yaml`

`version`, `status`, `decision`, `evidence_cutoff`, `candidates`, `eligibility_gates`, `comparison`, `nominations`, `watch_items`, `refusals`, `evidence_ceilings`, `reversal_conditions`, `product_feedback_handoff`, `assumptions`, `unknowns`, `sources`, `next_step`.

### 3. `docs/product-intelligence/opportunity-ranking-changelog.md`

Append only. Record version, cutoff, decision, candidates added, reclassified, nominated, refused, ranking changes, and reason.

## Boundaries

* Do not browse, contact, collect, modify code, alter a roadmap, or promise delivery.
* Do not let synthetic scenarios increase confidence or count as sources.
* Do not infer prevalence, demand, willingness to pay, economics, or product outcomes.
* Do not rank features or competitor parity.
* Do not erase counterevidence, refusals, or watch items.
* Do not bypass the shared Product feedback or product-opportunity-prioritization gates.

## Done when

* Every candidate traces to canonical observations and surviving patterns.
* Eligibility, evidence strength, consequence, fit, and counterevidence remain separate.
* No more than three bounded candidates are nominated.
* The Product feedback handoff preserves the observational evidence ceiling.
* Markdown, YAML, and changelog agree.