Scenario & Flow Mapper

Overview

Transform workflow decompositions into comprehensive scenario-based functional designs. The goal is systematic completeness, not creative output.

Core principle: Every workflow step has predictable scenario categories. Miss one category, miss entire classes of bugs.

The Scenario Generation Process

digraph scenario_generation {
    rankdir=TB;
    node [shape=box];

    input [label="1. Catalog Step Types\n(from workflow)"];
    patterns [label="2. Apply Pattern Templates\n(per step type)"];
    happy [label="3. Define Happy Paths\n(named, concrete)"];
    edge [label="4. Derive Edge Cases\n(boundary + unusual valid)"];
    failure [label="5. Map Failure Paths\n(with recovery)"];
    escalation [label="6. Extract Escalations\n(from judgment points)"];
    combine [label="7. Generate Combinations\n(multi-step scenarios)"];
    validate [label="8. Validate Coverage\n(checklist audit)"];

    input -> patterns -> happy -> edge -> failure -> escalation -> combine -> validate;
}

Step 1: Catalog Step Types

Every workflow step falls into one of these types:

Step 2: Apply Pattern Templates

For every step, generate scenarios using these templates:

System Trigger Scenarios

- TRIGGER_NORMAL: Standard input, all fields present
- TRIGGER_MINIMAL: Only required fields
- TRIGGER_DUPLICATE: Same input arrives twice
- TRIGGER_MALFORMED: Invalid format/structure
- TRIGGER_PARTIAL: Missing required fields
- TRIGGER_CONCURRENT: Multiple triggers simultaneously

Validation Scenarios

- VALIDATE_MATCH: All criteria pass
- VALIDATE_MISMATCH: Clear failure on one criterion
- VALIDATE_PARTIAL: Some criteria pass, some fail
- VALIDATE_AMBIGUOUS: Data unclear, needs human review
- VALIDATE_TIMEOUT: External service doesn't respond
- VALIDATE_STALE: Data changed since last check

Decision Scenarios

- DECIDE_BRANCH_N: One scenario per possible outcome
- DECIDE_BOUNDARY: Value exactly at threshold
- DECIDE_BELOW: Value just below threshold
- DECIDE_ABOVE: Value just above threshold
- DECIDE_UNKNOWN: Criteria don't clearly apply
- DECIDE_OVERRIDE: Manual override of automated decision

Human Task Scenarios

- HUMAN_COMPLETE: Task finished successfully
- HUMAN_ESCALATE: Worker uncertain, needs help
- HUMAN_TIMEOUT: No action within SLA
- HUMAN_REASSIGN: Worker transfers to colleague
- HUMAN_REJECT: Worker refuses task (conflict, etc.)
- HUMAN_PARTIAL: Incomplete work submitted

System Action Scenarios

- ACTION_SUCCESS: Completes as expected
- ACTION_FAILURE: Explicit error returned
- ACTION_TIMEOUT: No response within limit
- ACTION_PARTIAL: Some operations succeed, some fail
- ACTION_ROLLBACK: Need to undo completed action
- ACTION_RETRY: Transient failure, retry succeeds

Step 3: Define Happy Paths

Happy path criteria:

• All validations pass
• All decisions follow expected/common branch
• All actions succeed
• No escalations triggered
• Process completes end-to-end

Name each happy path with a persona:

happy_paths:
  - id: HP-001
    name: "[Persona Name] - [Distinguishing Characteristic]"
    persona:
      # Concrete, named individual
      # Specific attribute values
    flow:
      # Step-by-step expected path
    expected_outcome: "[Specific end state]"
    time_to_complete: "[Expected duration]"

Multiple happy paths if:

• Different valid customer types (retail vs business)
• Different products with different flows
• Different channels (online vs branch)

Step 4: Derive Edge Cases

Edge case = unusual but valid. The system should handle it correctly.

For each edge case, document:

edge_cases:
  - id: EC-001
    name: "[Descriptive name]"
    trigger: "[What makes this an edge case]"
    why_edge: "[Why this is unusual but valid]"
    expected_path: "[How system should handle]"
    boundary_value: "[Specific threshold if applicable]"

Step 5: Map Failure Paths

Failure = process cannot continue normally. Must define what happens next.

For every failure, answer:

1. What fails? (Specific step and condition)
2. How detected? (System check, human observation, external notification)
3. Immediate action? (Halt, retry, alert)
4. Recovery path? (How to resume or resolve)
5. Terminal condition? (When to give up)
6. Customer communication? (What they're told)

failure_paths:
  - id: FP-001
    name: "[Failure description]"
    failure_point: "[Step ID where failure occurs]"
    failure_condition: "[Specific trigger]"
    detection_method: "[How we know]"
    immediate_action: "[First response]"
    recovery_path: "[Steps to resolve]"
    terminal_if: "[When to stop trying]"
    customer_communication: "[Message sent]"
    data_preserved: "[What we keep for retry]"

Step 6: Extract Escalation Scenarios

Escalation = human judgment required beyond normal process.

Derive from judgment points in workflow:

• Every step with judgment.criteria: "UNKNOWN" needs escalation path
• Every decision with subjective criteria needs override path
• Every human task needs "uncertain" path

Escalation triggers:

escalation_scenarios:
  - id: ES-001
    name: "[Escalation description]"
    source_step: "[Where escalation originates]"
    trigger: "[Condition that causes escalation]"
    escalation_target: "[Who receives it]"
    information_required: "[What they need to decide]"
    decision_options: "[Possible outcomes]"
    sla: "[Time limit for resolution]"
    further_escalation: "[If still unresolved]"

Step 7: Generate Combination Scenarios

Not all scenarios are single-step. Test interactions:

combination_scenarios:
  - id: CS-001
    name: "[Combination description]"
    scenario_chain:
      - step: "[First event]"
        outcome: "[Result]"
      - step: "[Second event triggered by first]"
        outcome: "[Result]"
    expected_final_state: "[End result]"

Step 8: Validate Coverage

Completeness checklist - review before finalizing:

Per-Step Coverage

For EVERY step in workflow, verify you have scenarios for:

• Normal/success case
• At least one failure case
• Timeout/unavailable case (if external dependency)
• Boundary values (if thresholds exist)

Per-Judgment Coverage

For EVERY judgment point, verify:

• Each documented criterion has test case
• "UNKNOWN criteria" has escalation path
• Override/exception path exists

Cross-Cutting Coverage

• Happy path covers end-to-end
• At least one failure at each step
• All escalation targets have receiving scenarios
• System failure scenarios for each integration
• Concurrent/duplicate handling

Output Format

scenarios:
  workflow: "[Workflow name]"
  generated_date: "[Date]"

  step_catalog:
    - step_id: "[ID]"
      step_name: "[Name]"
      step_type: "[trigger|validation|decision|human_task|action]"
      has_judgment: [true|false]
      integrations: ["[External systems]"]

  happy_paths:
    - id: HP-001
      name: "[Persona] - [Characteristic]"
      persona: { ... }
      flow: [ ... ]
      expected_outcome: "[State]"

  edge_cases:
    - id: EC-001
      name: "[Name]"
      trigger: "[Trigger]"
      why_edge: "[Explanation]"
      expected_path: "[How handled]"

  failure_paths:
    - id: FP-001
      name: "[Name]"
      failure_point: "[Step]"
      recovery_path: "[Recovery]"
      terminal_if: "[Give up condition]"

  escalation_scenarios:
    - id: ES-001
      name: "[Name]"
      source_step: "[Step]"
      trigger: "[Condition]"
      escalation_target: "[Who]"

  combination_scenarios:
    - id: CS-001
      name: "[Name]"
      scenario_chain: [ ... ]

  coverage_validation:
    steps_with_no_failure_scenario: []
    judgments_without_escalation: []
    integrations_without_timeout_scenario: []
    gaps_identified: []

Common Mistakes

Red Flags in Your Analysis

If your output has these, you're not done:

• All scenarios are "success" or "failure" (missing edge cases)
• No boundary value scenarios
• Escalation scenarios without clear triggers
• Failure paths without recovery
• No combination scenarios
• Coverage checklist has gaps
• "Various edge cases may apply" instead of specific list

Financial Services Context

In regulated financial services:

• Every scenario must be auditable - Can you prove you tested this?
• Regulatory scenarios are mandatory - SAR triggers, AML thresholds, customer complaints
• Failure recovery is compliance-critical - What happens to in-flight applications during outage?
• Escalation paths must have owners - Regulators ask "who is responsible?"

The output of this analysis feeds directly into:

1. Developer test cases
2. QA acceptance criteria
3. Compliance evidence
4. Operational runbooks