convoke-agents 2.0.0

package/_bmad/bme/_vortex/workflows/research-convergence/steps/step-04-pains-gains.md

@@ -0,0 +1,77 @@
+---
+step: 4
+workflow: research-convergence
+title: Pains & Gains Analysis
+---
+
+# Step 4: Pains & Gains Analysis
+
+With your JTBD framed, we now map the specific pains users experience and gains they desire — grounded in artifact evidence.
+
+## Why This Matters
+
+Pains & Gains analysis reveals what users value versus what they tolerate. The data shows that understanding pains without gains leads to reactive solutions, while understanding gains without pains leads to solutions nobody needs urgently. You need both sides, cross-referenced against your JTBD from Step 3.
+
+## Your Task
+
+### 1. Map Pains
+
+For each pain point your research reveals, capture these fields (aligned with the HC2 schema):
+
+| Field | Description | Example |
+|-------|-------------|---------|
+| **Pain Description** | What the user struggles with | "Manually consolidating data from 6 tools every morning" |
+| **Priority** | `High` / `Medium` / `Low` | High |
+| **Frequency** | How often this pain is experienced | "Daily — every morning before standup" |
+| **Intensity** | How severely it affects the user | "Blocks all other work for 2 hours" |
+| **Evidence Sources** | Which artifacts support this pain | "Empathy map (artifact 1), Interview (artifact 2) — quote: '...'" |
+| **Current Coping** | How users deal with this today | "Built a personal spreadsheet that takes 30 min to update" |
+
+**Tips:**
+- Prioritize by impact on the JTBD — which pains most prevent the user from getting the job done?
+- Cross-reference against your Step 2 themes. These three pain points converge on a single root cause — look for that pattern.
+- Include at least 3 pains with evidence from multiple artifacts
+
+### 2. Map Gains
+
+For each desired gain, capture:
+
+| Field | Description | Example |
+|-------|-------------|---------|
+| **Gain Description** | What outcome the user desires | "See all campaign metrics in real-time without manual work" |
+| **Priority** | `High` / `Medium` / `Low` | High |
+| **Expected Impact** | How achieving this changes things | "Saves 2 hours daily, enables real-time optimization" |
+| **Evidence Sources** | Which artifacts support this gain | "Interview (artifact 2) — quote: 'If I could just see it all in one place...'" |
+
+**Tips:**
+- Gains should map to the expected outcome in your JTBD
+- Look for gains that resolve multiple pains simultaneously — those are your highest-leverage opportunities
+- Include at least 2 gains with artifact evidence
+
+### 3. Cross-Reference Against JTBD
+
+Now connect the dots:
+
+- **Does each pain relate to the JTBD situation or motivation?** If a pain doesn't connect to the job, it may be real but out of scope.
+- **Does each gain map to the JTBD expected outcome?** If a gain doesn't serve the outcome, it may be a nice-to-have rather than a core need.
+- **Are there pains with no corresponding gain, or gains with no corresponding pain?** These gaps signal areas where the research may be incomplete.
+
+---
+
+## Your Turn
+
+Map your pains and gains using the tables above, then cross-reference them against your JTBD from Step 3.
+
+---
+
+**[a]** Advanced Elicitation — Deep dive into Pains & Gains analysis with guided questioning
+**[p]** Party Mode — Bring in other Vortex agents for collaborative discussion
+**[c]** Continue — Move to synthesis and HC2 artifact creation
+
+---
+
+## Next Step
+
+When your pains and gains are mapped and cross-referenced, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/research-convergence/steps/step-05-synthesize.md

package/_bmad/bme/_vortex/workflows/research-convergence/steps/step-05-synthesize.md

@@ -0,0 +1,147 @@
+---
+step: 5
+workflow: research-convergence
+title: Synthesize & Route
+---
+
+# Step 5: Synthesize & Route
+
+Time to bring everything together. We've validated artifacts, analyzed cross-artifact patterns, framed the JTBD, and mapped pains and gains. Now we converge it all into a single HC2 Problem Definition artifact.
+
+## Why This Matters
+
+Problem definition is the highest-leverage activity in product discovery. A clear, evidence-backed problem statement prevents teams from building solutions to the wrong problem. Across all our research, the core problem is what we're about to articulate — and everything downstream (hypotheses, experiments, production signals) depends on getting this right.
+
+## Your Task
+
+### 1. Converged Problem Statement
+
+Write a single, clear problem statement that synthesizes everything:
+
+**Problem Statement:** One concise paragraph defining the core problem. This should feel like the inevitable conclusion of all your research — not a surprise.
+
+**Confidence:** `High` / `Medium` / `Low`
+- **High:** Multiple artifacts converge on the same problem with strong evidence
+- **Medium:** Evidence points in this direction but some gaps remain
+- **Low:** Best interpretation of limited or conflicting evidence
+
+**Scope:** What is explicitly in and out of scope for this problem.
+
+### 2. Evidence Summary
+
+Build the traceability record — how did we get here?
+
+| Field | Your Answer |
+|-------|-------------|
+| **Artifacts Analyzed** | How many HC1 artifacts (or other inputs) did you use? List them. |
+| **Total Evidence Points** | Count discrete quotes, observations, and data points across all artifacts. |
+| **Convergence Assessment** | How strongly do the pain points converge on a root cause? Do gains point to the same desired outcome? |
+| **Contradictions** | Where did artifacts disagree? How was this resolved? |
+| **Evidence Gaps** | What's missing that would strengthen this problem definition? |
+
+**Provenance:** For each major pain and gain, note which input artifact it originated from. This ensures traceability from problem definition back to raw research.
+
+### 3. Assumptions
+
+Every problem definition embeds assumptions. Make them explicit:
+
+| Assumption | Basis | Risk if Wrong | Validation Status |
+|------------|-------|---------------|-------------------|
+| *What we're assuming is true* | *Why it seems reasonable given evidence* | *What happens if this is incorrect* | `Validated` / `Partially Validated` / `Assumed` |
+
+### 4. Generate the HC2 Artifact
+
+I'll produce the HC2 Problem Definition artifact with this structure:
+
+```yaml
+---
+contract: HC2
+type: artifact
+source_agent: mila
+source_workflow: research-convergence
+target_agents: [liam]
+input_artifacts:
+  - path: "_bmad-output/vortex-artifacts/{your-hc1-artifact-1}"
+    contract: HC1
+  - path: "_bmad-output/vortex-artifacts/{your-hc1-artifact-2}"
+    contract: HC1
+created: YYYY-MM-DD
+---
+```
+
+**HC2 Required Body Sections:**
+1. **Converged Problem Statement** — Problem Statement, Confidence, Scope
+2. **Jobs-to-be-Done** — Primary JTBD (from Step 3) + Functional/Emotional/Social Jobs
+3. **Pains** — Prioritized pain table (from Step 4)
+4. **Gains** — Prioritized gain table (from Step 4)
+5. **Evidence Summary** — Traceability record (from above)
+6. **Assumptions** — Explicit assumptions table (from above)
+
+**Save to:** `{output_folder}/vortex-artifacts/hc2-problem-definition-{date}.md`
+
+I'll create this file with all the sections above once you confirm the content is ready.
+
+### 5. Validation Questions
+
+Before we finalize, let's validate:
+
+**Evidence Check:**
+- [ ] Is every pain and gain backed by at least one artifact reference?
+- [ ] Can we trace the JTBD back to specific research evidence?
+- [ ] Did we document contradictions honestly rather than hiding them?
+
+**Convergence Check:**
+- [ ] Does the problem statement follow naturally from the JTBD + Pains + Gains?
+- [ ] Would someone reading only the problem statement understand the core issue?
+- [ ] Is the confidence level honest given our evidence?
+
+**Actionability Check:**
+- [ ] Can Liam use this to generate testable hypotheses?
+- [ ] Are the assumptions specific enough to validate or invalidate?
+- [ ] Is the scope clear enough that Liam knows what's in and out of bounds?
+
+---
+
+## Your Turn
+
+Let's build the Converged Problem Statement, Evidence Summary, and Assumptions table. Confirm when you're ready for me to generate the final HC2 artifact.
+
+---
+
+**[a]** Advanced Elicitation — Deep dive into synthesis with guided questioning
+**[p]** Party Mode — Bring in other Vortex agents for collaborative discussion
+**[c]** Continue — Generate the HC2 artifact and proceed to routing
+
+---
+
+## Vortex Compass
+
+Based on what you just completed, here are your evidence-driven options:
+
+| If you learned... | Consider next... | Agent | Why |
+|---|---|---|---|
+| Problem is clearly defined with strong evidence | hypothesis-engineering | Liam 💡 | Converged problem ready for hypothesis generation (HC2) |
+| Research gaps or unvalidated assumptions remain | user-discovery | Isla 🔍 | More discovery needed before convergence is reliable |
+| The problem space itself seems wrong or too narrow | contextualize-scope | Emma 🎯 | Need to re-examine the broader problem context |
+
+> **Note:** These are evidence-based recommendations. You can navigate to any Vortex agent
+> at any time based on your judgment.
+
+**Or run Max's [VN] Vortex Navigation** for a full gap analysis across all streams.
+
+### ⚠️ Insufficient Evidence for Routing
+
+If the evidence gathered so far doesn't clearly point to a single next step:
+
+| To route to... | You need... |
+|----------------|-------------|
+| Liam 💡 | Converged problem definition with clear JTBD, pains, and gains |
+| Isla 🔍 | Identified knowledge gap, unvalidated assumption, or anomalous behavior |
+| Emma 🎯 | Clear signal that the problem space or scope needs fundamental change |
+
+**Workflow-specific signals:**
+- Cannot converge on a single JTBD from multiple artifacts → consider **Isla** for more discovery
+- Pain points from different artifacts contradict irreconcilably → consider **Emma** for re-scoping
+- Converged problem statement is vague or low-confidence → consider **Isla** for more evidence
+
+**Recommended:** Revisit earlier steps to strengthen your evidence, or run **Max's [VN] Vortex Navigation** for a full gap analysis.

package/_bmad/bme/_vortex/workflows/research-convergence/workflow.md

@@ -0,0 +1,50 @@
+---
+workflow: research-convergence
+type: step-file
+description: Synthesize divergent research into a single JTBD-grounded problem definition
+author: Mila (research-convergence-specialist)
+version: 1.6.0
+---
+
+# Research Convergence Workflow
+
+This workflow guides you through synthesizing divergent research findings into a single, actionable problem definition grounded in Jobs-to-be-Done framing and Pains & Gains analysis.
+
+## What is Research Convergence?
+
+Research convergence is the process of taking multiple streams of research — empathy maps, interview syntheses, observation reports — and distilling them into one clear problem statement. Instead of scattered insights, you get a single, evidence-backed definition of what problem to solve and why it matters.
+
+Here's what the research is telling us: divergent findings are not a sign of confusion. They're the raw material for a strong problem definition. This workflow helps you connect the dots.
+
+## Workflow Structure
+
+**Step-file architecture:**
+- Just-in-time loading (each step loads only when needed)
+- Sequential enforcement (must complete step N before step N+1)
+- State tracking in frontmatter (progress preserved)
+
+## Steps Overview
+
+1. **Setup & Input Validation** - Validate and list your input artifacts (HC1 empathy artifacts or other research)
+2. **Context Loading & Analysis** - Load artifacts and identify themes, patterns, and contradictions
+3. **Jobs-to-be-Done Framing** - Frame the core job using JTBD structure: When [situation], I want to [motivation], so I can [outcome]
+4. **Pains & Gains Analysis** - Map pains and gains grounded in artifact evidence
+5. **Synthesize & Route** - Converge into a single HC2 problem definition and route via Compass
+
+## Output
+
+**Artifact:** HC2 Problem Definition markdown file in `{output_folder}/vortex-artifacts/hc2-problem-definition-{date}.md`
+
+**Template:** None (HC2 artifact is generated inline during Step 5)
+
+**Schema:** Conforms to HC2 contract (`_bmad/bme/_vortex/contracts/hc2-problem-definition.md`)
+
+**Consumer:** Liam (hypothesis-engineering) uses this to ground hypothesis generation in a validated problem.
+
+---
+
+## INITIALIZATION
+
+Load config from {project-root}/_bmad/bme/_vortex/config.yaml
+
+Load step: {project-root}/_bmad/bme/_vortex/workflows/research-convergence/steps/step-01-setup.md

package/_bmad/bme/_vortex/workflows/signal-interpretation/steps/step-01-setup.md

@@ -0,0 +1,68 @@
+---
+step: 1
+workflow: signal-interpretation
+title: Setup & Input Validation
+---
+
+# Step 1: Setup & Input Validation
+
+Before we interpret any production signals, we need to understand the experiment that produced the current state. Production data is the most honest user feedback — it can't lie — but it means nothing without the experiment context that gives it meaning.
+
+## Why This Matters
+
+A production metric viewed in isolation is just a number. A 20% drop in feature adoption could be alarming or exactly what the experiment predicted. The signal indicates something very different depending on which experiment graduated to production, what hypothesis was tested, and what behavior was expected. Without that experiment context, you're reading tea leaves instead of intelligence.
+
+## Your Task
+
+### 1. What Experiment Context Do You Have?
+
+Noah expects experiment context — ideally produced by Wade's experimentation workflow as an HC4-compliant artifact:
+- **HC4 Experiment Context** (from Wade's `lean-experiment` workflow)
+- **HC4 Experiment Context** (from Wade's `proof-of-concept`, `proof-of-value`, or `mvp` workflows)
+
+You can also bring **any well-formed experiment summary** — Noah accepts input from outside the Vortex pattern. It doesn't have to be HC4-compliant, but having structured experiment results with explicit success criteria and confirmed/rejected hypotheses makes signal interpretation dramatically more precise.
+
+### 2. Provide Your Input
+
+Please provide the file path or describe the experiment context you want to interpret signals for. For example:
+- `_bmad-output/vortex-artifacts/hc4-experiment-context-2026-02-25.md`
+- Or: "I have experiment results and production metrics I'd like to analyze"
+
+### 3. Input Validation
+
+I'll check your artifact against the HC4 schema to assess readiness:
+
+**HC4 Frontmatter Check:**
+- `contract: HC4`
+- `type: artifact`
+- `source_agent` (who produced it)
+- `source_workflow` (which workflow)
+- `target_agents: [noah]`
+- `input_artifacts` (upstream references)
+- `created` (date)
+
+**HC4 Body Section Check:**
+- Experiment Summary (Name, Description, Type, Duration, Graduation Status)
+- Hypothesis Tested (Statement, Riskiest Assumption, Expected Outcome, Target Behavior Change)
+- Experiment Method (Method Type, Sample Size, Planned Duration)
+- Pre-Defined Success Criteria (Metric, Target Threshold, Actual Result, Met?)
+- Additional Results (optional — Quantitative Metrics, Qualitative Results)
+- Confirmed/Rejected Hypotheses (Status, Assumption Status, Core Learning)
+- Strategic Context (Vortex Stream, Assumption Tested, Decision It Informs, Implications)
+- Production Readiness (Metrics to Monitor, Expected Production Behavior, Signal Thresholds)
+
+**If your input is non-conforming:** That's fine — we don't reject experiment context. I'll guide you to identify which elements are present and which gaps we need to work around during signal interpretation. The more complete the experiment context, the more precise the signal analysis. But even partial context is better than none — here's what we're seeing in context with whatever you can provide.
+
+> For the full HC4 schema reference, see `{project-root}/_bmad/bme/_vortex/contracts/hc4-experiment-context.md`
+
+---
+
+## Your Turn
+
+Please provide your experiment context — file path, description, or both. I'll validate it and we'll proceed to connecting it with your production signal.
+
+## Next Step
+
+When your experiment context is provided and validated, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/signal-interpretation/steps/step-02-context.md

package/_bmad/bme/_vortex/workflows/signal-interpretation/steps/step-02-context.md

@@ -0,0 +1,67 @@
+---
+step: 2
+workflow: signal-interpretation
+title: Experiment Context & Signal Connection
+---
+
+# Step 2: Experiment Context & Signal Connection
+
+Now that we have validated experiment context, let's connect it to the production signal you're investigating. Raw metrics mean nothing without interpretation frames — this step builds those frames.
+
+## Why This Matters
+
+Every production signal has a lineage. The feature behavior you're seeing didn't appear from nowhere — it emerged from a specific experiment that tested a specific hypothesis about specific user behavior. When that lineage is explicit, the signal tells a story. When it's missing, the signal is just noise. Here's what we're seeing in context: that's the difference between intelligence and dashboards.
+
+## Your Task
+
+### 1. Extract Experiment Lineage
+
+Let's trace the experiment that produced the current production state:
+
+| Field | Your Input |
+|-------|-----------|
+| **Originating Experiment** | Name and reference to the HC4 experiment that led to this production state |
+| **Original Hypothesis** | The hypothesis that was tested (from HC4 Section 2) |
+| **Experiment Outcome** | Was the hypothesis confirmed, rejected, or partially confirmed? (from HC4 Section 6) |
+| **Expected Production Behavior** | What was expected to happen in production based on experiment results (from HC4 Section 8) |
+| **Actual vs Expected** | How does the observed production signal compare to what was predicted? |
+
+This is the core of signal interpretation — connecting what you're seeing now to what was expected based on the experiment. If actual matches expected, the signal confirms the experiment. If it diverges, that divergence is the signal worth investigating.
+
+### 2. Map the Vortex History
+
+Production signals don't exist in isolation within the Vortex journey. Let's connect to the broader context:
+
+| Field | Your Input |
+|-------|-----------|
+| **Problem Definition** | Reference to the HC2 problem definition that started this Vortex journey (if available) |
+| **Hypothesis Origin** | Reference to the HC3 hypothesis contract that this experiment tested (if available) |
+| **Previous Signals** | References to any prior HC5 signal reports for this experiment or feature (if any) |
+| **Related Experiments** | Other experiments that may be influencing the same production area |
+
+Not all of these will be available — that's fine. Each connection adds depth to your signal interpretation. Even without formal Vortex artifacts, understanding the broader experiment history enriches the analysis.
+
+### 3. Describe the Production Signal
+
+Now let's identify the specific production signal you want to interpret:
+
+| Field | Your Input |
+|-------|-----------|
+| **What are you observing?** | Describe the production behavior or metric that prompted this analysis |
+| **When did it start?** | Time window of the observation |
+| **Who is affected?** | Which users, segments, or features show this signal |
+| **How was it detected?** | Monitoring alert, user report, manual analysis, routine metric review |
+
+This gives us the raw signal that we'll analyze in depth during Step 3.
+
+---
+
+## Your Turn
+
+Extract your experiment lineage, map the Vortex history connections you have available, and describe the production signal you're investigating. The more context you provide here, the more precise the signal analysis will be in the next step.
+
+## Next Step
+
+When your experiment context is connected and the production signal is described, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/signal-interpretation/steps/step-03-signal-analysis.md

package/_bmad/bme/_vortex/workflows/signal-interpretation/steps/step-03-signal-analysis.md

@@ -0,0 +1,85 @@
+---
+step: 3
+workflow: signal-interpretation
+title: Signal Description & Trend Analysis
+---
+
+# Step 3: Signal Description & Trend Analysis
+
+Now we move from context to analysis. We have the experiment lineage, the Vortex history, and a production signal to investigate. This step produces two core components of the HC5 signal report: a factual signal description and a data-driven trend analysis.
+
+## Why This Matters
+
+Signal + context + trend — that's the interpretation frame. Without all three, you're guessing. The signal description tells you what happened. The context (from Step 2) tells you why it matters. The trend analysis tells you where it's heading. Together, they produce intelligence that a dashboard cannot — because dashboards show numbers, not narratives grounded in experiment history.
+
+## Your Task
+
+### 1. Signal Description
+
+Describe the production signal factually. No interpretation yet — just what happened.
+
+| Field | Your Analysis |
+|-------|-------------|
+| **Signal Summary** | One-sentence factual description of what was observed in production |
+| **Signal Type** | `Metric Deviation` / `Behavior Pattern` / `Anomaly` / `Trend Shift` / `Threshold Breach` |
+| **Severity** | `Critical` / `Warning` / `Informational` |
+| **Detection Method** | How the signal was detected (monitoring alert, user report, metric analysis, routine review) |
+| **Time Window** | When the signal was observed (date range) |
+| **Affected Scope** | Which users, segments, or features are affected |
+
+**Guidance on severity:**
+- **Critical:** Signal indicates production behavior that contradicts experiment predictions or poses immediate risk
+- **Warning:** Signal shows meaningful deviation from expected behavior that warrants investigation
+- **Informational:** Signal shows minor deviation or confirms expected behavior — worth documenting but not alarming
+
+### 2. Trend Analysis
+
+Now let's analyze the signal's trajectory. The signal indicates a direction — let's quantify it:
+
+| Field | Your Analysis |
+|-------|-------------|
+| **Trend Direction** | `Improving` / `Degrading` / `Stable` / `Oscillating` / `Insufficient Data` |
+| **Trend Duration** | How long the trend has been observed (e.g., "2 weeks", "since launch") |
+| **Rate of Change** | How quickly the signal is moving (e.g., "5% week-over-week decline", "steady 2% monthly growth") |
+| **Baseline Comparison** | Comparison to pre-experiment or validated baseline — how does the current state compare to what existed before the experiment? |
+| **Confidence** | `High` / `Medium` / `Low` — based on data quality and sample size |
+
+**Guidance on trend direction:**
+- **Improving:** Signal is moving toward expected/desired behavior
+- **Degrading:** Signal is moving away from expected behavior — divergence increasing
+- **Stable:** Signal is holding steady — no significant change
+- **Oscillating:** Signal is fluctuating without a clear direction
+- **Insufficient Data:** Not enough data points to determine a trend reliably
+
+### 3. Connect Signal to Experiment Expectations
+
+This is where signal interpretation lives — connecting what you're seeing to what was predicted:
+
+| Question | Your Assessment |
+|----------|----------------|
+| **Does the signal align with experiment predictions?** | Does production behavior match what the experiment predicted in its Production Readiness section? |
+| **Where does it diverge?** | What specific aspects of the signal differ from experiment expectations? |
+| **Is the divergence within tolerance?** | Is the gap between actual and expected within acceptable ranges, or does it warrant deeper investigation? |
+| **What does the trend suggest?** | Is the divergence growing, shrinking, or stable over time? |
+
+**Remember:** Noah observes and reports. Strategic decisions about what to do with this intelligence belong downstream with Max. The signal indicates what's happening — the decision about what it means for the product direction is not ours to make.
+
+---
+
+## Your Turn
+
+Complete the signal description and trend analysis tables. Connect the signal to experiment expectations and assess where actual behavior diverges from predicted behavior.
+
+---
+
+**[a]** Advanced Elicitation — Deep dive into signal patterns with guided questioning
+**[p]** Party Mode — Bring in other Vortex agents for collaborative signal interpretation
+**[c]** Continue — Proceed to anomaly detection and data quality assessment
+
+---
+
+## Next Step
+
+When your signal description and trend analysis are complete, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/signal-interpretation/steps/step-04-anomaly-detection.md

package/_bmad/bme/_vortex/workflows/signal-interpretation/steps/step-04-anomaly-detection.md

@@ -0,0 +1,93 @@
+---
+step: 4
+workflow: signal-interpretation
+title: Anomaly Detection & Data Quality
+---
+
+# Step 4: Anomaly Detection & Data Quality
+
+We've described the signal and analyzed its trend. Now we look for what doesn't fit — unexpected behavior patterns not covered by the original hypothesis — and assess whether the data underlying our analysis is trustworthy.
+
+## Why This Matters
+
+Anomaly detection surfaces what dashboards hide. Dashboards show you what you asked to measure. Anomalies show you what you didn't think to measure — behavior patterns that fall outside the experiment's prediction model. These unexpected patterns are often the most valuable signals because they reveal user intent that the original hypothesis didn't anticipate. And before we package any of this as intelligence, we need to know how much we can trust the data.
+
+## Your Task
+
+### 1. Anomaly Detection
+
+Look beyond the expected signal. Behavioral patterns reveal intent that surveys miss — and anomalies reveal what the experiment model didn't predict.
+
+**Does the production data show unexpected behavior not covered by the original hypothesis?**
+
+If unexpected patterns are present, document them:
+
+| Field | Your Analysis |
+|-------|-------------|
+| **Anomaly Description** | What unexpected behavior was observed? Describe it factually. |
+| **Deviation from Expected** | How does this differ from what the experiment predicted? What did the hypothesis expect vs. what actually happened? |
+| **Potential Explanations** | Possible reasons for the anomaly — factual explanations only, not speculative strategy |
+| **Discovery Needed** | Does this warrant routing to Isla for investigation? `Yes` / `No` |
+| **Discovery Focus** | If yes: What specific questions should Isla investigate about this anomaly? |
+
+**Guidance on anomaly identification:**
+- Look for user segments behaving differently than predicted
+- Check for usage patterns the experiment didn't measure
+- Examine edge cases where the feature is being used in unexpected ways
+- Compare actual user flows to the experiment's expected behavior model
+- Look for timing patterns — are behaviors different at different times or stages?
+
+**If no anomalies detected:** Document that production behavior aligns with experiment predictions within expected tolerance. This is a valid and valuable finding — it confirms the experiment's model.
+
+### 2. HC10 Anomaly Routing Assessment
+
+If you identified anomalies that warrant discovery research:
+
+**HC10 Routing Flag:**
+When unexpected behavior is detected that falls outside the experiment's hypothesis, this signals a potential routing to Isla for discovery research. The anomaly information passed to Isla includes:
+- Anomaly description + how it deviates from experiment expectations
+- Suggested discovery focus questions
+
+This routing will be presented in the Vortex Compass during Step 5. For now, document whether an HC10 flag is appropriate based on your anomaly analysis.
+
+| Assessment | Your Decision |
+|-----------|--------------|
+| **Anomalous behavior detected?** | Yes / No |
+| **HC10 routing recommended?** | Yes / No |
+| **Rationale** | Why or why not — what makes this anomaly significant enough (or not) for discovery research? |
+
+### 3. Data Quality Assessment
+
+Before we package this analysis as intelligence, let's assess the reliability of the data:
+
+| Field | Your Assessment |
+|-------|----------------|
+| **Sample Size** | Volume of data underlying this signal — is it sufficient for the conclusions drawn? |
+| **Data Completeness** | Was data collection complete, or were there gaps? (e.g., tracking failures, partial rollouts, missing segments) |
+| **Known Biases** | Any sampling or measurement biases that may affect interpretation (e.g., self-selection, survivorship bias, time-of-day effects) |
+| **Confidence Level** | `High` / `Medium` / `Low` — overall confidence in the signal analysis given data quality |
+
+**Guidance on confidence:**
+- **High:** Large sample, complete data, no known biases — conclusions are reliable
+- **Medium:** Adequate sample but some gaps or potential biases — conclusions are directionally sound but should be interpreted with caveats
+- **Low:** Small sample, significant gaps, or notable biases — conclusions are preliminary and should not drive major decisions without additional data
+
+---
+
+## Your Turn
+
+Complete the anomaly detection analysis, assess whether HC10 routing to Isla is warranted, and evaluate data quality. If no anomalies were detected, document that finding — it's equally important.
+
+---
+
+**[a]** Advanced Elicitation — Deep dive into anomaly investigation with guided questioning
+**[p]** Party Mode — Bring in other Vortex agents for collaborative anomaly assessment
+**[c]** Continue — Proceed to synthesis and HC5 artifact generation
+
+---
+
+## Next Step
+
+When your anomaly detection and data quality assessment are complete, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/signal-interpretation/steps/step-05-synthesize.md