Observational problem-pattern synthesis

# Observational problem-pattern synthesis

## Goal

Turn the normalized observational ledger into bounded problem patterns organized by actor, situation, job, failed outcome, and workaround—without converting public noise into product validation.

This is local synthesis. Do not browse, collect, contact, generate synthetic personas, recommend features, or change code.

## Required prior artifacts

Read:

* `docs/product-intelligence/product-job-baseline.*`
* `docs/product-intelligence/research-policy.*`
* `docs/product-intelligence/evidence-ledger.*`

Advance only from ledger `NORMALIZE` or `NORMALIZE NARROWLY`. A ledger `HOLD` forces `HOLD`. Inherit every narrow question, actor, source-class, and coverage limit.

Inspect prior `docs/product-intelligence/problem-patterns.*` artifacts and preserve stable pattern IDs, rejected patterns, and history.

## Evidence contract

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

Atomic ledger items remain observations. A pattern is always `DERIVED`, because it groups and interprets observations. Its members, method, counterevidence, and evidence ceiling must be visible.

Repeated mentions within a convenience sample can strengthen confidence that the pattern exists in that sample. They cannot establish market prevalence, demand for this product, willingness to pay, adoption, retention, or realized value.

## Step 1: Establish eligibility

An eligible pattern must name:

* an actor or explicit actor unknown
* a triggering situation
* a job or desired progress
* an observed failed outcome, risk, delay, cost, or workaround
* at least one canonical observation ID
* relationship to the current product boundary

Reject clusters that are only shared keywords, feature requests, competitor capabilities, general sentiment, or “make it easier.” Keep different actors and situations separate even when they request the same solution.

## Step 2: Generate candidate patterns

Group conceptually related observations. For each candidate record:

* stable pattern ID and concise job-level name
* actor, situation, job, failed outcome, and consequence
* current alternative or workaround
* member observation IDs by source kind and stream
* independent-source count or `UNKNOWN`
* positive, negative, null, and contradictory evidence
* date and coverage boundary
* current-product relevance
* assumptions, unknowns, and plausible alternative interpretations

Do not count a source, repost, copied complaint, or competitor announcement more than once for independence.

## Step 3: Test pattern strength

Assess separate dimensions without collapsing them into one score:

* directness of the underlying observations
* independence and diversity of source classes
* consistency across actors and situations
* recency and temporal persistence
* consequence within the described workflow
* quality of workaround evidence
* counterevidence and source-selection bias
* fit with the product boundary

Use qualitative levels with explicit rules. Unknown inputs remain unknown. A vivid statement cannot compensate for weak independence or fit.

## Step 4: Seek disconfirmation

For each credible pattern, identify evidence that:

* the workaround is satisfactory or intentionally controlled
* the problem belongs to a different segment or job
* the issue is temporary, version-specific, or already resolved
* the sample overrepresents dissatisfied or technical contributors
* competitors already solve the job adequately
* the public statement is unsupported by behavior

Write the strongest rival explanation and what evidence would distinguish it. Do not force a winner where conflicts remain.

## Step 5: Classify patterns

Choose one per candidate:

* `CREDIBLE`: sufficiently direct, independent, relevant, and bounded for synthetic stress testing
* `CREDIBLE NARROWLY`: usable only for a named actor, situation, or research question
* `WATCH`: real signal but insufficient consequence, independence, recency, or fit
* `REJECT`: duplicate artifact, off-boundary cluster, unsupported interpretation, or contradicted pattern

Classification does not authorize product work.

## Decision

Choose exactly one:

* `SYNTHESIZE`: at least one credible bounded pattern may enter synthetic stress testing
* `SYNTHESIZE NARROWLY`: only named patterns and boundaries may advance
* `HOLD`: no pattern clears the synthesis threshold

Lead with:

> As of [cutoff], [N] credible and [N] narrowly credible problem patterns were derived from [N] canonical observations across [N] independent source classes, at coverage [limits], decision [SYNTHESIZE / SYNTHESIZE NARROWLY / HOLD].

## Required outputs

Create or update only:

### 1. `docs/product-intelligence/problem-patterns.md`

Decision, method, eligible and rejected candidates, pattern records, strength tests, counterevidence, rival explanations, classifications, coverage, assumptions, unknowns, and sources.

### 2. `docs/product-intelligence/problem-patterns.yaml`

`version`, `status`, `decision`, `evidence_cutoff`, `patterns`, `strength_tests`, `counterevidence`, `rival_explanations`, `classifications`, `rejections`, `coverage`, `assumptions`, `unknowns`, `sources`, `next_step`.

### 3. `docs/product-intelligence/problem-patterns-changelog.md`

Append only. Record version, cutoff, decision, patterns added, merged, split, reclassified, rejected, and why.

## Boundaries

* Do not browse, contact, collect, generate personas, or modify code.
* Do not promote a pattern above `DERIVED`.
* Do not infer market prevalence, demand, willingness to pay, or product value.
* Do not convert requests or competitor features into problems.
* Do not erase status-quo evidence, contradictions, or rejected patterns.
* Do not prescribe solutions.

## Done when

* Every pattern names its member observations and derivation.
* Actor, situation, job, failure, and workaround are explicit.
* Strength, fit, and counterevidence are evaluated separately.
* Advancement boundaries are precise enough for synthetic stress testing.
* The three outputs agree.