Synthetic scenario and edge-case stress testing

# Synthetic scenario and edge-case stress testing

## Goal

Use clearly labeled generated scenarios to challenge credible observational problem patterns, expose missing actors and edge cases, and design falsification questions without pretending generated reactions are customer evidence.

Synthetic work is a reasoning instrument, not feedback. Every generated scenario, persona fragment, objection, behavior, quote, probability, or outcome is `ASSUMED`. Synthetic material cannot increase source count, pattern strength, prevalence, demand, willingness to pay, or validation status.

Do not browse, contact anyone, modify code, or add synthetic items to the observational ledger.

## Required prior artifacts

Read:

* `docs/product-intelligence/product-job-baseline.*`
* `docs/product-intelligence/research-policy.*`
* `docs/product-intelligence/problem-patterns.*`

Advance only from `SYNTHESIZE` or `SYNTHESIZE NARROWLY`, inheriting the exact approved patterns and boundaries. A prior `HOLD` forces `HOLD`.

Inspect prior `docs/product-intelligence/synthetic-stress-test.*` artifacts and preserve stable scenario and challenge IDs.

## Evidence contract

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

Inherited source facts retain their labels. Every newly generated element must include:

* `evidence: ASSUMED`
* the inherited pattern and source IDs that constrain it
* the reason the scenario is useful
* the observation that could support or reject it

Do not generate or infer protected or sensitive traits. Use role, workflow, permission, environment, experience level, organization constraint, and failure condition only when they are product-relevant and grounded in the approved boundary.

Never fabricate customer names, organizations, quotes, ratings, interviews, tickets, usage events, revenue, or citations.

## Step 1: Build the scenario frame

For each advancing problem pattern, define axes that could materially change the interpretation:

* actor and permission level
* first use versus repeated use
* simple versus high-volume workflow
* complete versus missing or malformed input
* connected versus offline or integration failure
* low-risk versus safety-, privacy-, or money-sensitive consequence
* individual versus multi-party handoff
* successful workaround versus failed workaround

Use only relevant axes. Do not create demographic theater or exhaustive combinatorics.

## Step 2: Generate bounded scenarios

Create a small contrasting set for each pattern:

* strongest-case scenario
* status-quo-wins scenario
* wrong-actor or wrong-job scenario
* failure and recovery edge case
* permission, privacy, accessibility, or support edge case when relevant
* low-frequency but high-consequence case when supported by the domain boundary

Each scenario must separate inherited observations from generated assumptions. Do not write fake first-person testimonials or simulated interview transcripts.

## Step 3: Challenge the pattern

For each scenario ask:

* Does the same problem still exist?
* Could the observed workaround be the preferred solution?
* Is the consequence product-relevant or external?
* Which assumption carries the conclusion?
* What counterevidence would reverse it?
* What is the smallest passive observation or later product behavior that could discriminate between explanations?

Record contradictions and scenario-dependent boundaries. A pattern that survives only one favorable scenario should be narrowed, not strengthened.

## Step 4: Build edge-case and unknown registers

List:

* product states and inputs absent from public evidence
* actors or permissions missing from the sample
* unobserved failure and recovery paths
* trust, adoption, support, and switching assumptions
* measurements needed after a future release
* claims that no-contact research cannot resolve

Unknowns stay `UNKNOWN`; a generated answer cannot close them.

## Step 5: Produce falsification probes

Write passive or future-behavior probes, not invented results. Examples include a public-source query, repository check, aggregate telemetry definition, controlled product exposure measure, or outcome observation window.

Do not execute probes, instrument analytics, launch experiments, or claim a planned observation occurred.

## Decision

Choose exactly one:

* `STRESS TEST`: the approved patterns have bounded scenarios, challenges, and falsification probes
* `STRESS TEST NARROWLY`: only named patterns remain coherent enough to advance
* `HOLD`: generated challenges reveal that the inherited patterns are too ambiguous or unsupported to rank responsibly

Lead with:

> As of [date], [N] observational patterns were challenged by [N] explicitly synthetic scenarios; [N] remain coherent, [N] narrowed, and [N] failed, with all generated material `ASSUMED`, decision [STRESS TEST / STRESS TEST NARROWLY / HOLD].

## Required outputs

Create or update only:

### 1. `docs/product-intelligence/synthetic-stress-test.md`

Decision, synthetic-use disclaimer, scenario frame, scenarios, pattern challenges, narrowed or failed patterns, edge cases, unknowns, falsification probes, and inherited sources.

### 2. `docs/product-intelligence/synthetic-stress-test.yaml`

`version`, `status`, `decision`, `synthetic_evidence_rule`, `scenario_axes`, `scenarios`, `pattern_challenges`, `narrowed_patterns`, `failed_patterns`, `edge_cases`, `unknowns`, `falsification_probes`, `inherited_sources`, `next_step`.

### 3. `docs/product-intelligence/synthetic-stress-test-changelog.md`

Append only. Record version, decision, scenario frame changes, patterns narrowed or failed, probes changed, and reason.

## Boundaries

* Do not browse, contact, collect, interview, survey, modify code, or run experiments.
* Do not generate fake quotes, transcripts, people, organizations, events, or metrics.
* Do not add synthetic content to the observational ledger.
* Do not use synthetic volume or consistency as confidence.
* Do not infer protected or sensitive attributes.
* Do not close an `UNKNOWN` with generated material.

## Done when

* Every generated element is explicitly `ASSUMED` and traceable to its purpose.
* Contrasting and status-quo scenarios challenge each advancing pattern.
* Failed and narrowed patterns remain visible.
* Probes specify future evidence without claiming execution.
* Markdown, YAML, and changelog agree.