convoke-agents 2.0.0

package/_bmad/bme/_vortex/workflows/assumption-mapping/steps/step-03-risk-mapping.md

@@ -0,0 +1,103 @@
+---
+step: 3
+workflow: assumption-mapping
+title: Classification & Risk Mapping
+---
+
+# Step 3: Classification & Risk Mapping
+
+You've surfaced every assumption hiding in your hypotheses. Now let's classify each one by how lethal it is and how little we actually know — and build a risk map that tells you exactly what to validate first.
+
+## Why This Matters
+
+Not all assumptions are created equal. Some are annoying if wrong — you adjust and move on. Others are lethal — the entire hypothesis collapses. The riskiest assumption gets tested first, not the easiest one. This step transforms your assumption inventory into an actionable risk map with a clear testing order. No more guessing about what to validate next.
+
+## Your Task
+
+### 1. Classify Each Assumption
+
+For every assumption in your inventory from Step 2, assess two dimensions:
+
+**Lethality** — If this assumption is wrong, what happens to the hypothesis?
+
+| Level | Definition | Signal |
+|-------|-----------|--------|
+| **High** | Kills the hypothesis entirely. The whole idea collapses. | "If this is wrong, nothing else matters." |
+| **Medium** | Requires a significant pivot. The direction changes but the core insight survives. | "If this is wrong, we'd need to rethink the approach." |
+| **Low** | Minor adjustment needed. The core idea survives. | "If this is wrong, we tweak and continue." |
+
+**Uncertainty** — How much evidence do we actually have?
+
+| Level | Definition | Signal |
+|-------|-----------|--------|
+| **High** | No evidence. We're guessing. | "We believe this but have nothing to back it up." |
+| **Medium** | Some evidence, but indirect or incomplete. | "We have signals, but they're not conclusive." |
+| **Low** | Strong evidence from multiple sources. | "Multiple data points confirm this." |
+
+**Challenge yourself:** If a classification feels comfortable, it's probably wrong. High-lethality assumptions often get downgraded to medium because the team doesn't want to face the risk. What if it's actually high?
+
+### 2. Build the Assumption Risk Map
+
+| # | Assumption | Hypothesis | Lethality | Uncertainty | Priority | Validation Status |
+|---|-----------|-----------|-----------|-------------|----------|-------------------|
+| 1 | *Statement* | H1 | High/Med/Low | High/Med/Low | *Derived* | `Unvalidated` |
+| 2 | *Statement* | H1, H2 | High/Med/Low | High/Med/Low | *Derived* | `Unvalidated` |
+
+**Priority derivation (lethality × uncertainty):**
+
+|  | High Uncertainty | Medium Uncertainty | Low Uncertainty |
+|--|-----------------|-------------------|-----------------|
+| **High Lethality** | **Test First** | **Test First** | Monitor |
+| **Medium Lethality** | **Test Soon** | Test Soon | Monitor |
+| **Low Lethality** | Test Soon | Monitor | Monitor |
+
+- **Test First:** High lethality + High/Medium uncertainty = validate before any experiment. These assumptions could destroy your hypothesis and you don't have evidence either way.
+- **Test Soon:** Medium risk = validate early in the experiment cycle. Important but not immediately lethal.
+- **Monitor:** Low risk = track but don't delay for validation. The hypothesis survives even if these are wrong.
+
+### 3. Produce the Recommended Testing Order
+
+Based on the risk map, sequence your assumptions for validation:
+
+| Priority | Assumption | Hypothesis | Lethality × Uncertainty | Suggested Method | Minimum Evidence |
+|----------|-----------|-----------|------------------------|-----------------|-----------------|
+| 1 | *Riskiest — test this first* | H1 | High × High | *How to test it* | *What would validate or invalidate* |
+| 2 | *Next riskiest* | H2 | High × Medium | | |
+| 3 | *And so on* | H1, H3 | Medium × High | | |
+
+**Tiebreaker rules:**
+1. If two assumptions have equal priority, test the one that affects the **most hypotheses** first — if it's wrong, it invalidates more.
+2. If still tied, test the one with the **highest lethality** first — a lethal assumption is worse than an uncertain one.
+3. If still tied, test the one that's **cheapest to validate** — get quick signal before investing in expensive validation.
+
+### 4. Flag Concerns for Routing
+
+If any assumptions feel too risky to test through experiments alone — too uncertain, too lethal, or requiring user research before you can even design an experiment — flag them:
+
+| Concern | Assumption # | Impact | Recommended Action |
+|---------|-------------|--------|-------------------|
+| *Unvalidated assumption or knowledge gap* | 1 | *How it affects hypothesis quality* | *e.g., "Route to Isla for targeted user discovery"* |
+
+These flags may trigger routing to Isla in the Compass step — sending specific assumptions back for validation before proceeding to Wade's experiments.
+
+**Guidance:** Don't flag everything. Flag the assumptions where you genuinely don't know enough to design an experiment. If you can design an experiment to test it, it belongs in the testing order, not the flagged concerns.
+
+---
+
+## Your Turn
+
+Classify every assumption by lethality × uncertainty, build the risk map, produce the testing order, and flag any concerns. Share your analysis and I'll help you challenge any classifications that feel too comfortable.
+
+---
+
+**[a]** Advanced Elicitation — Deep dive into assumption classification with guided questioning
+**[p]** Party Mode — Bring in other Vortex agents to challenge your risk assessments
+**[c]** Continue — Proceed to synthesis and routing
+
+---
+
+## Next Step
+
+When your assumption risk map and testing order are complete, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/assumption-mapping/steps/step-04-synthesize.md

package/_bmad/bme/_vortex/workflows/assumption-mapping/steps/step-04-synthesize.md

@@ -0,0 +1,101 @@
+---
+step: 4
+workflow: assumption-mapping
+title: Synthesize & Route
+---
+
+# Step 4: Synthesize & Route
+
+You've extracted every assumption, classified each by lethality and uncertainty, and built a risk map with a testing order. Now let's validate the analysis is complete and figure out what happens next.
+
+## Why This Matters
+
+A risk map is only useful if it's honest. Before you act on it, we need to verify that every assumption was classified fairly, the testing order makes strategic sense, and the flagged concerns are genuine — not just the uncomfortable ones you want to avoid. If you can't prove it wrong, it's not a hypothesis — and if your risk map doesn't challenge you, it's not a risk map.
+
+## Your Task
+
+### 1. Review Your Assumption Risk Map
+
+Verify the risk classifications from Step 3:
+
+- [ ] Every assumption from the inventory has a lethality and uncertainty score
+- [ ] No assumptions were conveniently classified as low-risk to avoid confronting them
+- [ ] Cross-hypothesis assumptions (affecting multiple hypotheses) are flagged as higher priority
+- [ ] Priorities are correctly derived from the lethality × uncertainty matrix
+
+### 2. Review Your Testing Order
+
+Verify the testing sequence makes strategic sense:
+
+- [ ] Testing order prioritizes by lethality × uncertainty, not by convenience or cost
+- [ ] Tiebreakers were applied correctly (most hypotheses affected → highest lethality → cheapest to validate)
+- [ ] Each assumption has a suggested method and minimum evidence threshold
+- [ ] The order would survive scrutiny from a skeptic — is this really the right sequence?
+
+### 3. Review Flagged Concerns
+
+If you flagged concerns for routing to Isla:
+
+- [ ] Flagged concerns are genuinely unresolvable through experiments alone
+- [ ] Each flag has a specific research question, not a vague "we need more info"
+- [ ] The recommended action is actionable — Isla would know exactly what to investigate
+
+### 4. Final Challenge
+
+Before we route, stress-test the whole analysis:
+
+**Completeness Check:**
+- [ ] Did we surface unstated assumptions, not just the obvious ones?
+- [ ] Did we challenge comfortable classifications?
+- [ ] Would a different team arrive at the same risk map given the same hypotheses?
+
+**Honesty Check:**
+- [ ] Is the riskiest assumption truly the most lethal, or the most visible?
+- [ ] Are the "Monitor" assumptions genuinely low-risk, or are we avoiding them?
+- [ ] Does the testing order reflect strategic priority, not emotional comfort?
+
+---
+
+## Your Turn
+
+Review the assumption risk map, testing order, and flagged concerns. Confirm when you're satisfied that the analysis is honest and complete.
+
+---
+
+**[a]** Advanced Elicitation — Deep dive into risk map validation with guided questioning
+**[p]** Party Mode — Bring in other Vortex agents to challenge your risk assessments
+**[c]** Continue — Proceed to routing
+
+---
+
+## Vortex Compass
+
+Based on what you just completed, here are your evidence-driven options:
+
+| If you learned... | Consider next... | Agent | Why |
+|---|---|---|---|
+| High-risk assumptions need validation before any experiment | user-discovery | Isla 🔍 | Unvalidated lethal assumptions need discovery research first |
+| Assumptions are acceptable — riskiest are testable | lean-experiment | Wade 🧪 | Assumptions acceptable, proceed to test (HC3) |
+| Hypotheses need refinement based on what the risk map revealed | hypothesis-engineering | Liam 💡 | Refine hypotheses based on risk map |
+
+> **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... |
+|----------------|-------------|
+| Isla 🔍 | Specific high-risk assumption identified with clear research question |
+| Wade 🧪 | Risk map complete with acceptable risk profile and testing order |
+| Liam 💡 | Clear signal that hypothesis contracts need structural revision |
+
+**Workflow-specific signals:**
+- All assumptions scored low-risk → may not need this workflow; proceed to Wade
+- Cannot classify assumptions due to vague hypotheses → revisit **Liam's hypothesis-engineering** for sharper contracts
+- Multiple lethal assumptions with no clear priority → consider routing to **Isla** for targeted discovery
+
+**Recommended:** Revisit earlier steps to strengthen your risk map, or run **Max's [VN] Vortex Navigation** for a full gap analysis.

package/_bmad/bme/_vortex/workflows/assumption-mapping/workflow.md

@@ -0,0 +1,49 @@
+---
+workflow: assumption-mapping
+type: step-file
+description: Deep-dive assumption analysis across hypothesis contracts — classify by lethality and uncertainty, prioritize testing order, and surface hidden risks
+author: Liam (hypothesis-engineer)
+version: 1.6.0
+---
+
+# Assumption Mapping Workflow
+
+This workflow guides you through a deep analysis of the assumptions embedded in your hypothesis contracts — surfacing hidden risks, classifying each assumption by lethality and uncertainty, and producing a prioritized testing order so you validate the right things first.
+
+## What is Assumption Mapping?
+
+Every hypothesis is a bet — and every bet hides assumptions. Assumption mapping is the discipline of dragging those assumptions into the open, classifying how lethal they are, and figuring out which ones to test first.
+
+What if your riskiest assumption isn't the one you think it is? Most teams test the comfortable assumptions — the ones they can validate cheaply — and ignore the lethal ones until it's too late. This workflow forces you to confront the assumptions that could kill your hypotheses before you invest in experiments.
+
+If you can't prove it wrong, it's not a hypothesis. And if you haven't mapped what could prove it wrong, you're not ready to test it.
+
+## 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 your hypothesis contracts (HC3 artifact or equivalent input)
+2. **Assumption Inventory & Extraction** - Extract all assumptions — stated and unstated — from every hypothesis contract
+3. **Classification & Risk Mapping** - Classify by lethality × uncertainty, build the risk map, produce testing order
+4. **Synthesize & Route** - Review the risk map, validate completeness, and route via Compass
+
+## Output
+
+**Working Document:** Enriched assumption risk map with prioritized testing order. This workflow deepens your assumption analysis — the output informs your next move (back to hypothesis refinement, forward to experiments, or to Isla for discovery).
+
+**Template:** None (assumption risk map is produced inline during Steps 3-4)
+
+**Consumer:** Wade (lean-experiment) consumes the testing order when assumptions are acceptable. Isla (user-discovery) investigates high-risk assumptions that need validation. Liam (hypothesis-engineering) refines hypotheses when the risk map reveals structural weaknesses.
+
+---
+
+## INITIALIZATION
+
+Load config from {project-root}/_bmad/bme/_vortex/config.yaml
+
+Load step: {project-root}/_bmad/bme/_vortex/workflows/assumption-mapping/steps/step-01-setup.md

package/_bmad/bme/_vortex/workflows/behavior-analysis/steps/step-01-setup.md

@@ -0,0 +1,81 @@
+---
+step: 1
+workflow: behavior-analysis
+title: Setup & Input Validation
+---
+
+# Step 1: Setup & Input Validation
+
+Before we analyze any production behavior, we need the experiment that established the baseline. Behavioral patterns reveal intent that surveys miss — but only when measured against what was predicted and validated. Without that baseline, observed behavior is just noise.
+
+## Why This Matters
+
+Production behavior viewed in isolation tells you what users are doing. Production behavior viewed against experiment baselines tells you what it means. A segment abandoning a feature could be alarming — or it could be exactly the variance the experiment predicted. The classification depends entirely on the experiment context: what was tested, what was confirmed, and what behavior was expected in production. Without those baselines, you cannot distinguish variance from regression from discovery.
+
+## 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 behavior analysis dramatically more precise.
+
+### 2. Provide Your Input
+
+Please provide the file path or describe the experiment context and the behavior you want to analyze. For example:
+- `_bmad-output/vortex-artifacts/hc4-experiment-context-2026-02-25.md`
+- Or: "I have experiment results and I'm seeing unexpected user behavior in production"
+
+### 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 behavior analysis. The more complete the experiment context, the sharper the baseline comparison. But even partial context is better than none — here's what we're seeing in context with whatever you can provide.
+
+### 4. Describe the Behavior You're Observing
+
+While I validate your experiment context, describe the production behavior that prompted this analysis:
+
+| Field | Your Observation |
+|-------|-----------------|
+| **What behavior are you seeing?** | Describe the specific user behavior or pattern you've noticed |
+| **How does it differ from what you expected?** | What did you expect users to do vs. what they're actually doing? |
+| **When did you first notice it?** | Approximate time frame |
+| **Which users or segments?** | Who is exhibiting this behavior? |
+
+This gives us the raw observation that we'll compare against experiment baselines in Step 2.
+
+> For the full HC4 schema reference, see `{project-root}/_bmad/bme/_vortex/contracts/hc4-experiment-context.md`
+
+---
+
+## Your Turn
+
+Please provide your experiment context and describe the behavior you're observing. I'll validate the experiment input and we'll proceed to establishing baselines for comparison.
+
+## Next Step
+
+When your experiment context is provided and validated, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/behavior-analysis/steps/step-02-context.md

package/_bmad/bme/_vortex/workflows/behavior-analysis/steps/step-02-context.md

@@ -0,0 +1,67 @@
+---
+step: 2
+workflow: behavior-analysis
+title: Experiment Baselines & Behavior Observation
+---
+
+# Step 2: Experiment Baselines & Behavior Observation
+
+Now that we have validated experiment context, let's extract the baselines that define what "expected behavior" looks like — and document the observed behavior we'll classify against those baselines.
+
+## Why This Matters
+
+Behavior only becomes meaningful when compared to what was expected. The experiment established baselines: success criteria were met (or not), specific metrics were validated, and production behavior was predicted. Those baselines are the ruler against which every observed behavior is measured. Without explicit baselines, classification is guesswork. With them, the signal indicates whether production is confirming the experiment, diverging from it, or revealing something the experiment never anticipated.
+
+## Your Task
+
+### 1. Extract Experiment Baselines
+
+From the HC4 artifact (or equivalent), extract the validated baselines that behavior will be compared against:
+
+| Field | Your Baseline |
+|-------|-------------|
+| **Validated Success Metrics** | Which metrics were confirmed in the experiment? What were the actual values? |
+| **Expected Production Behavior** | What behavior did the experiment predict for production? (from HC4 Section 8) |
+| **Signal Thresholds** | What thresholds were defined for acceptable vs. concerning behavior? (from HC4 Section 8) |
+| **Target Behavior Change** | What specific user behavior change was the experiment designed to produce? (from HC4 Section 2) |
+| **Confirmed Hypothesis Elements** | Which parts of the hypothesis were confirmed? These define what "expected" means. |
+
+These baselines form the comparison frame for Step 3's classification. Every observed behavior will be measured against these specific, experiment-validated benchmarks.
+
+### 2. Document the Behavior Observation
+
+Now let's formalize the behavior observation from Step 1 into a structured description:
+
+| Field | Your Observation |
+|-------|-----------------|
+| **Behavior Summary** | One-sentence factual description of the production behavior being analyzed |
+| **Observation Period** | When the behavior was observed (date range) |
+| **Affected Users/Segments** | Which users, segments, or features exhibit this behavior |
+| **Detection Method** | How the behavior came to attention (monitoring, user report, manual analysis, routine review) |
+| **Behavioral Metrics** | Specific metrics that capture this behavior (e.g., adoption rate, usage frequency, task completion) |
+| **Comparison to Baseline** | Initial assessment — how does this behavior compare to the experiment baselines extracted above? |
+
+### 3. Map the Vortex History
+
+Production behavior doesn'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 behavior analysis. Even without formal Vortex artifacts, understanding the broader experiment history enriches the classification.
+
+---
+
+## Your Turn
+
+Extract your experiment baselines, document the behavior observation, and map available Vortex history connections. The more precise the baselines, the more accurate the classification in the next step.
+
+## Next Step
+
+When your experiment baselines are extracted and behavior is documented, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/behavior-analysis/steps/step-03-classification.md

package/_bmad/bme/_vortex/workflows/behavior-analysis/steps/step-03-classification.md

@@ -0,0 +1,98 @@
+---
+step: 3
+workflow: behavior-analysis
+title: Behavior Pattern Classification
+---
+
+# Step 3: Behavior Pattern Classification
+
+We have the experiment baselines and the observed behavior. Now we classify what the behavior means. This is the core of behavior analysis — converting raw observation into categorized intelligence that tells the decision-maker whether production is confirming, regressing, or revealing.
+
+## Why This Matters
+
+Classification converts raw observation into actionable intelligence. Without classification, a behavior pattern is just a data point. With classification, it becomes a signal with clear routing implications: expected variance means the experiment model is holding, regression means something validated is degrading, and novel behavior means users are telling you something the experiment didn't ask. Each classification carries different weight and routes to different next steps. The signal indicates different things depending on which category the behavior falls into.
+
+## Your Task
+
+### 1. Behavior Pattern Analysis
+
+Compare the observed behavior to your experiment baselines. Analyze across multiple dimensions:
+
+| Dimension | Your Analysis |
+|-----------|-------------|
+| **Metric Comparison** | How do the behavioral metrics compare to experiment-validated thresholds? Within tolerance or outside? |
+| **Segment Behavior** | Are all user segments behaving consistently, or are specific segments diverging? |
+| **Usage Patterns** | Do usage patterns match what the experiment predicted? Frequency, duration, feature paths? |
+| **Timing** | Is the behavior consistent over time, or does it vary by time of day, week, or stage of adoption? |
+| **Edge Cases** | Are edge cases or boundary conditions producing unexpected behavior? |
+| **Feature Interaction** | Are users interacting with the feature in ways the experiment didn't measure? |
+
+### 2. Classify Each Behavior Pattern
+
+For each distinct behavior pattern observed, classify it into one of three categories:
+
+#### Category 1: Expected Variance
+
+Behavior falls within experiment-predicted tolerance. The experiment model is holding.
+
+| Field | Your Classification |
+|-------|-------------------|
+| **Behavior** | What specific behavior falls within expected range |
+| **Baseline Reference** | Which experiment baseline confirms this is expected |
+| **Tolerance Range** | What variance was predicted? Where does the observed behavior fall? |
+| **Confidence** | How certain is this classification? |
+
+#### Category 2: Regression
+
+Behavior diverges negatively from validated experiment performance. Something that was working is degrading.
+
+| Field | Your Classification |
+|-------|-------------------|
+| **Behavior** | What specific behavior is degrading from validated performance |
+| **Baseline Reference** | Which validated metric is being underperformed |
+| **Deviation** | How far has behavior moved from the validated baseline? Quantify. |
+| **Trajectory** | Is the regression accelerating, decelerating, or stable? |
+| **Possible Factors** | What observable factors might be contributing? (factual only, not speculative strategy) |
+
+#### Category 3: Novel Behavior
+
+Behavior not covered by the original experiment hypothesis. Users are doing something the experiment didn't predict.
+
+| Field | Your Classification |
+|-------|-------------------|
+| **Behavior** | What behavior was observed that the experiment didn't anticipate |
+| **Why It's Novel** | How does this fall outside the experiment's prediction model? |
+| **Scope** | How widespread is this behavior? Which users, how frequently? |
+| **Behavioral Signal** | What might this behavior indicate about user intent? (observational, not prescriptive) |
+
+### 3. Classification Summary
+
+Summarize all classified behavior patterns:
+
+| # | Behavior Pattern | Classification | Key Evidence | Confidence |
+|---|-----------------|---------------|-------------|-----------|
+| 1 | *describe* | Expected Variance / Regression / Novel | *key metric* | High / Medium / Low |
+| 2 | *(if applicable)* | | | |
+| 3 | *(if applicable)* | | | |
+
+**Remember:** Noah classifies and reports. Strategic decisions about what to do with these classifications belong downstream with Max. The classification tells you what the behavior is — the decision about what it means for the product direction is not ours to make.
+
+---
+
+## Your Turn
+
+Analyze the behavior patterns against experiment baselines, classify each into the appropriate category, and complete the classification summary. Share your analysis and I'll help refine the classifications before we move to evidence gathering.
+
+---
+
+**[a]** Advanced Elicitation — Deep dive into behavior classification with guided questioning
+**[p]** Party Mode — Bring in other Vortex agents for collaborative behavior pattern analysis
+**[c]** Continue — Proceed to evidence gathering and data quality assessment
+
+---
+
+## Next Step
+
+When your behavior patterns are classified, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/behavior-analysis/steps/step-04-evidence.md

package/_bmad/bme/_vortex/workflows/behavior-analysis/steps/step-04-evidence.md

@@ -0,0 +1,100 @@
+---
+step: 4
+workflow: behavior-analysis
+title: Evidence Gathering & Data Quality
+---
+
+# Step 4: Evidence Gathering & Data Quality
+
+We've classified the behavior patterns. Now we build the evidence base that supports each classification and assess whether the data underlying our analysis is trustworthy. Evidence strength determines routing confidence — the stronger the evidence, the more decisive the Compass recommendation.
+
+## Why This Matters
+
+Classification without evidence is opinion. Evidence converts classification into intelligence. For each behavior pattern classified in Step 3, we need quantified metrics, specific comparisons to baselines, and honest assessment of data quality. And before we package any of this as intelligence, we need to know how much we can trust the data. Anomaly detection surfaces what dashboards hide — but only when the evidence is solid enough to support the finding.
+
+## Your Task
+
+### 1. Evidence Gathering by Classification
+
+For each behavior pattern classified in Step 3, gather supporting evidence:
+
+**For Expected Variance classifications:**
+
+| Field | Your Evidence |
+|-------|-------------|
+| **Metric Match** | Specific metrics showing behavior within experiment-predicted tolerance |
+| **Baseline Alignment** | How closely does observed behavior track the validated baseline? |
+| **Duration** | How long has the behavior been within expected range? |
+| **Consistency** | Is the variance consistent across segments, or concentrated in specific groups? |
+
+**For Regression classifications:**
+
+| Field | Your Evidence |
+|-------|-------------|
+| **Deviation Metrics** | Specific metrics showing divergence from validated performance, quantified |
+| **Regression Timeline** | When did the regression start? How has it progressed? |
+| **Rate of Change** | How quickly is the regression occurring? (e.g., "3% week-over-week decline") |
+| **Scope Impact** | Which users/segments/features are affected and to what degree? |
+| **Contributing Factors** | Observable factors that correlate with the regression (factual, not speculative) |
+
+**For Novel Behavior classifications:**
+
+| Field | Your Evidence |
+|-------|-------------|
+| **Behavior Metrics** | Specific metrics capturing the novel behavior pattern |
+| **Experiment Gap** | What specifically was not measured or predicted by the experiment? |
+| **Scope & Frequency** | How many users, how often, in what contexts? |
+| **Behavioral Context** | What are users doing before and after the novel behavior? |
+| **Discovery Questions** | What specific questions would need answers to understand this behavior? |
+
+### 2. HC10 Novel Behavior Routing Assessment
+
+If you identified Novel Behavior in Step 3, assess whether it warrants routing to Isla for discovery research:
+
+| Assessment | Your Decision |
+|-----------|--------------|
+| **Novel behavior detected?** | Yes / No |
+| **HC10 routing recommended?** | Yes / No |
+| **Rationale** | Why or why not — what makes this novel behavior significant enough (or not) for discovery research? |
+| **Discovery Focus** | If yes: What specific questions should Isla investigate about this behavior? |
+
+**Guidance on HC10 routing:**
+- Route to Isla when novel behavior reveals user intent the experiment didn't anticipate
+- Route to Isla when the behavior pattern is widespread enough to warrant investigation
+- Do NOT route if the novel behavior is isolated, transient, or easily explained by external factors
+
+### 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 the behavior analysis — is it sufficient for the classifications made? |
+| **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 classification (e.g., self-selection, survivorship bias, time-of-day effects) |
+| **Confidence Level** | `High` / `Medium` / `Low` — overall confidence in the behavior classifications given data quality |
+
+**Guidance on confidence:**
+- **High:** Large sample, complete data, no known biases — classifications are reliable
+- **Medium:** Adequate sample but some gaps or potential biases — classifications are directionally sound but should be interpreted with caveats
+- **Low:** Small sample, significant gaps, or notable biases — classifications are preliminary and should not drive major decisions without additional data
+
+---
+
+## Your Turn
+
+Gather evidence for each classification, assess whether novel behavior warrants HC10 routing to Isla, and evaluate data quality. The strength of your evidence determines the confidence of the final behavioral signal report.
+
+---
+
+**[a]** Advanced Elicitation — Deep dive into evidence strengthening with guided questioning
+**[p]** Party Mode — Bring in other Vortex agents for collaborative evidence assessment
+**[c]** Continue — Proceed to synthesis and HC5 artifact generation
+
+---
+
+## Next Step
+
+When your evidence gathering and data quality assessment are complete, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/behavior-analysis/steps/step-05-synthesize.md