references/methods-define.md

# Define method cards

## Affinity Clustering — `supplemental_design_practice`

Group evidence records by emergent similarity, name clusters after grouping, test alternate arrangements, and retain source IDs. Preserve unclustered records. Avoid using desired features as cluster labels. A contradiction is not automatically an outlier: keep a counterexample beside the theme it qualifies; reserve the outlier area for records without a defensible relationship. Lock a source-card deck containing stable ID, provenance, and original wording before clustering. If that complete stable-ID deck is already visible in the user's prompt or immediately preceding context, acknowledge it as locked and arrange by ID without echoing it; otherwise print it once before any cluster label. A provenance count alone does not satisfy this source-first boundary. Show the provisional arrangement, boundary cards, materially different alternate grouping when one exists, and outliers. End with one concrete analytical or research move that tests the most consequential interpretation. In `WORKSHOP` view, render an `AFFINITY_MAP` through `render_visual.py`; the spatial artifact may reproduce note wording where needed for inspection, but the visual grouping is an interpretation and must not change provenance.

**Participatory route:** expose card IDs and invite one move or cluster rename at a time. Preserve each move as `USER_PROVIDED`, retain the prior arrangement in history, and redraw only when the board materially changes.

## Pattern Finding — `public_design_practice`

Look across stories for repeated mechanisms, sequence breaks, adaptations, emotional shifts, and context differences. Record frequency only within the sample and preserve negative cases. Output patterns plus scope and exceptions.

## Need Finding — `public_design_practice`

Translate evidence into verbs, capacities, or desired states. Ask whether multiple solutions could address it and whether it survives banning the current concept. Output evidence-linked need candidates; never name a feature as a need.

## Tension Finding — `mightshape_original`

Identify goals, values, constraints, or roles that pull against each other: speed versus control, consistency versus local adaptation, dignity versus surveillance. A tension is not a flaw to resolve immediately; it may be the frame.

## Contradiction Mining — `mightshape_original`

Examine say/do gaps, source conflict, exceptions, reversals, and differences between roles. Offer several explanations and identify what evidence would distinguish them. Do not accuse participants of inconsistency as moral failure.

## Insight Generation — `public_design_practice`

Connect evidence, pattern/tension, interpretation, and design opportunity. A strong insight is non-obvious, human-centered, generative, and disprovable enough to investigate. Label inference and cite inputs.

## 2×2 Matrix — `public_design_practice`

Choose two meaningful, independent dimensions; place evidence or concepts; inspect gaps, clusters, and relationships; then challenge the axes. Use for exploration, not automatic market segmentation or proof. Until a dedicated 2×2 renderer exists, preserve a structured text matrix rather than forcing data into an affinity wall.

## Why-How Laddering — `public_design_practice`

Move upward with “why does that matter?” toward meaning and downward with “how might that happen?” toward actionability. Stop before empty universals or solution features. Use the ladder to find a generative altitude.

## Powers of Ten — `public_design_practice`

Change temporal, social, geographic, organizational, or system scale. Ask what remains true for one person, 10× scale, a ten-minute episode, or a decade. Output alternate frames and scale-dependent assumptions.

## Alternative Frames — `mightshape_original`

Generate at least obvious, behavioral, systems, and counterintuitive readings when warranted. State evidence for and against each, stakeholders centered/excluded, and different solution territories each would open.

## Point of View — `public_design_practice`

Write `specific user/context + solution-independent need + evidence-linked insight`. Generate several narrow POVs rather than one vague umbrella. Score heuristically, preserve competing frames, and list assumptions.

**Participatory route:** facilitate one component per turn. Gently coach solution-laden needs, explain the narrowing risk, and let the user revise or retain their wording without grading it.

## How Might We — `public_design_practice`

Turn a POV into several generative questions: direct, amplify, remove, invert, question an assumption, extreme user, scale, analogy, constraint, impossible ideal, and system intervention. Avoid embedding a solution or producing a question too broad to guide action.

**Participatory route:** offer one transformation example, then ask for or invite revision of one HMW at a time. Keep competing prompts visible.