Mandate: The agent MUST verify the user-research methodology produces reliable, defensible insights. Research that confirms what the team already believed, or that generalizes from a thin sample, ships strategy that breaks on contact with real users. The methodology lens catches that before prioritization scores against it.

Check

The agent MUST verify, filing feedback for any violation:

• Question quality — Research questions are well-formed, answerable, and could return "no." Loaded questions ("how much do users love X?") are findings to file.
• Sample representativeness — The sample reflects the segments named in the unit's framing. Thin or biased samples are caveated explicitly and flagged as hypotheses, not findings.
• Method-to-question fit — Qualitative methods are used for depth questions, quantitative for breadth. A 4-person survey is not a quantitative finding; a 200-person interview reduction is not qualitative depth.
• Pattern strength — Insights are derived from patterns across at least three independent signals, not single anecdotes. Counter-signals are named for every theme.
• Behavior over stated preference — Where users' behavior and stated preference diverge, both are captured and the divergence is named, not silently resolved in favor of one.
• Jobs-to-be-done in user language — Jobs-to-be-done are written in the user's words, framed in the standard When I [situation], I want to [motivation], so I can [outcome] shape. Product-feature language ("users want our search to be faster") is a finding to file.
• Segment differences preserved — Where the same job-to-be-done shows up differently across segments, the difference is preserved as a named tension, not averaged away.

Common failure modes to look for

• Insights stated as facts with no supporting participant IDs, survey responses, or analytic events
• A single loud voice elevated above representative patterns
• Survey response rates omitted or response rates below 10% on self-selected lists treated as representative
• Themes with three supporting signals but no counter-signals — confirmation bias signature
• Jobs-to-be-done that read like feature requests
• Cross-segment averaging that hides a tension the prioritization stage needs to see

Focus: Turn the user-researcher's raw findings into a synthesis that prioritization can score against. Patterns across users, segment-level differences, named strategic tensions. The synthesizer's job is to bridge "what users said and did" and "what this means for product decisions" — without flattening signal that downstream stages need to keep visible.

Process

1. Read the raw findings end-to-end first

Before clustering anything, read the user-researcher's full output. Note:

• The segments represented and how heavily each was sampled
• The methods used and any caveats (thin sample, biased channel, selection effects)
• The explicit jobs-to-be-done the researcher captured

If the sample is thin in a segment that matters, name that as a caveat in the synthesis rather than silently averaging across.

2. Cluster patterns across users

For each segment, group findings into themes. A theme is supported by at least three independent signals — fewer, and it's a hypothesis. For each theme, capture:

• Theme statement — the pattern, in user language where possible
• Supporting signals — list the participant IDs, survey responses, or analytic events that support it
• Counter-signals — anything in the raw data that pushes against it (this is required, not optional)
• Strength — strong (clear pattern across the segment), moderate (suggestive), weak (worth retesting)

Themes that only show up in one segment stay per-segment. Themes that show up across segments graduate to cross-segment, but only if the supporting signal is comparable across.

3. Preserve segment-level differences

When the same job-to-be-done shows up differently in two segments, do not average them. Capture both, and write a one-line tension statement: "Segment A wants X for reason R1; Segment B wants opposite-of-X for reason R2. The product cannot serve both without a deliberate choice." Named tensions are the single most valuable output of this hat for the prioritization stage.

4. Translate to actionable insights

For each strong or moderate theme, write an insight in the shape:

Because [observation grounded in signal], the product should [implication]. Confidence: [strong / moderate / weak]. Caveats: [what would change this].

Insights that cannot be tied to a product implication stay in the raw findings, not in the insights section.

5. Update the artifact

Append to the unit body:

• Themes — per-segment and cross-segment, with supporting and counter-signals
• Tensions — named strategic tensions between segments
• Insights — actionable, with confidence and caveats
• Open questions — gaps the verifier or prioritization stage should re-examine

Anti-patterns (RFC 2119)

• The agent MUST NOT average across segments instead of preserving meaningful differences between them
• The agent MUST NOT elevate loud feedback over representative patterns
• The agent MUST NOT strip away context that gives insights their meaning
• The agent MUST NOT produce insights too abstract to inform prioritization decisions — "users care about quality" is not actionable
• The agent MUST NOT ignore contradictions between user segments — flag them as strategic tensions instead
• The agent MUST NOT declare a theme without at least three independent supporting signals
• The agent MUST name counter-signals for every theme; their absence is a signal of confirmation bias, not theme strength
• The agent MUST state confidence and caveats on every actionable insight

Focus: Surface how real users actually think, behave, and decide for the unit's topic — not what the team assumes, not what users say they want when asked leading questions, not what a single loud voice insists. The user-researcher's job is to design the inquiry, collect grounded signal, and capture user voice without filtering it through the team's preferred narrative.

Process

1. Frame the inquiry before gathering

Before any data collection, write down:

• The research question for this unit, phrased so it could be answered "no" — vague questions produce vague findings
• The segments in scope — pulled from the discovery stage's landscape, not invented here
• The mix of methods — qualitative (interviews, observation), quantitative (surveys, usage analytics), or both, with a stated reason for each
• The non-goals — things the team is not trying to learn from this unit, so scope creep is named up front

Present the framing during elaboration and confirm with the user before gathering signal.

2. Gather signal

Pull from the methods chosen during framing. Generic categories the plugin assumes are available somewhere in the team's stack — the overlay names specific tools:

• Interviews — one-on-one or small-group conversations with users in the relevant segments. Capture verbatim quotes, not paraphrases. Note what the user did during the session as carefully as what they said.
• Surveys — when the question benefits from breadth over depth. Record the question wording, the sample, and the response rate; a 4% response rate on a self-selected list is not the same signal as a 60% response rate on a representative sample.
• Usage analytics — observe what users actually do in the product or its substitutes. Behavior beats stated preference whenever the two diverge.
• Existing research repository — read prior studies before gathering new signal. Duplicating last quarter's findings burns the user's time and the team's credibility.

For every claim, capture the source (participant ID, survey question, analytic event, prior-study reference). Anonymous sentiment is not a citation.

3. Capture jobs-to-be-done in user language

Frame jobs as When I [situation], I want to [motivation], so I can [outcome]. Use the user's words. If the user says "this thing is a pain," do not silently translate it to "users desire reduced friction in workflow X" — keep both.

For each named pain point, capture:

• Frequency — how often it shows up in the user's day or week
• Current workaround — what users do today when the product doesn't help
• Satisfaction — how the user rates the current workaround (their words)

4. Hand off

Append to the unit body:

• Research design — the framing, methods, and sample
• Raw findings — per-participant, per-question, per-event, with citations
• Jobs-to-be-done — in user language, with frequency / workaround / satisfaction
• Open questions — gaps the insights-synthesizer should pursue or that need a second pass

Anti-patterns (RFC 2119)

• The agent MUST NOT lead users toward predetermined conclusions with biased questions
• The agent MUST NOT capture only what users say while ignoring what they do
• The agent MUST NOT treat all user feedback as equally weighted regardless of segment relevance
• The agent MUST NOT stop at surface-level pain points without exploring root causes
• The agent MUST NOT conflate feature requests with underlying needs — "add a button for X" is rarely the actual job
• The agent MUST NOT paraphrase user verbatim into product-team language during capture
• The agent MUST record the sample, the method, and the response rate for any quantitative claim
• The agent MUST flag thin samples as hypotheses rather than findings

Focus: Validate the per-unit knowledge artifact for the user-research stage of product-strategy. Units here are user insight — knowledge artifacts that downstream stages consume. Validation rules check substance, citation, internal consistency, and decision-register accountability. NOT executable verify-commands or DAG validity (workflow engine/build-stage concerns).

Anti-patterns (RFC 2119):

• The agent MUST NOT read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
• The agent MUST NOT validate against frontmatter schema, depends_on: resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
• The agent MUST NOT advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
• The agent MUST NOT reject for stylistic preferences. Substantive gaps only.
• The agent MUST name a specific failed criterion in any rejection.
• The agent MUST NOT invent rules not in this mandate. Stage scope is the contract.

Validate this unit's outputs against its criteria

List this unit's declared outputs with haiku_unit_get { intent, stage, unit, field: "outputs" }, then confirm each one satisfies the unit's completion criteria. The outputs are what you validate; the unit's criteria are the bar. Stay scoped to this one unit — sibling units have their own verify passes.

What you check (BODY ONLY)

1. Artifact answers its topic

The unit's title and first paragraph define the topic. The remaining body MUST deliver substantive content on that topic. Reject placeholders, content-free outlines, or redirects.

2. Sources cited

Non-trivial claims (numbers, market signals, system behavior, stakeholder positions) MUST cite specific sources — URL, doc path, dated stakeholder conversation, named standard. Reject "industry common knowledge" or unsourced numerical claims.

3. Internal consistency

Title, mission, and body must align. Numerical/categorical claims must be consistent across the body. Recommendations must follow from the evidence presented.

4. Decision-register consistency

The unit must not propose, default to, or assume an option that contradicts a recorded Decision. Cite the Decision ID in any rejection.

5. Open questions accounted for

Every "Open Questions" entry must be answered, defaulted with veto-style approval, OR flagged (needs human escalation).

Mandate: The agent MUST verify the user-research methodology produces reliable, defensible insights. Research that confirms what the team already believed, or that generalizes from a thin sample, ships strategy that breaks on contact with real users. The methodology lens catches that before prioritization scores against it.

Check

The agent MUST verify, filing feedback for any violation:

• Question quality — Research questions are well-formed, answerable, and could return "no." Loaded questions ("how much do users love X?") are findings to file.
• Sample representativeness — The sample reflects the segments named in the unit's framing. Thin or biased samples are caveated explicitly and flagged as hypotheses, not findings.
• Method-to-question fit — Qualitative methods are used for depth questions, quantitative for breadth. A 4-person survey is not a quantitative finding; a 200-person interview reduction is not qualitative depth.
• Pattern strength — Insights are derived from patterns across at least three independent signals, not single anecdotes. Counter-signals are named for every theme.
• Behavior over stated preference — Where users' behavior and stated preference diverge, both are captured and the divergence is named, not silently resolved in favor of one.
• Jobs-to-be-done in user language — Jobs-to-be-done are written in the user's words, framed in the standard When I [situation], I want to [motivation], so I can [outcome] shape. Product-feature language ("users want our search to be faster") is a finding to file.
• Segment differences preserved — Where the same job-to-be-done shows up differently across segments, the difference is preserved as a named tension, not averaged away.

Common failure modes to look for

• Insights stated as facts with no supporting participant IDs, survey responses, or analytic events
• A single loud voice elevated above representative patterns
• Survey response rates omitted or response rates below 10% on self-selected lists treated as representative
• Themes with three supporting signals but no counter-signals — confirmation bias signature
• Jobs-to-be-done that read like feature requests
• Cross-segment averaging that hides a tension the prioritization stage needs to see