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

dot

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 Type	Definition	Scenario Focus
system_trigger	External event starts the process	Input variations, missing data, duplicates
validation	Compare/verify data	Match, mismatch, partial match, timeout
decision	Route based on criteria	Each branch, boundary values, unknown
human_task	Requires human action	Complete, escalate, timeout, reassign
system_action	Automated execution	Success, failure, partial, timeout, rollback

Step 2: Apply Pattern Templates

For every step, generate scenarios using these templates:

System Trigger Scenarios

yaml

- 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

yaml

- 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

yaml

- 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

yaml

- 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

yaml

- 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:

yaml

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.

Edge Type	Definition	Example
Boundary	Value at exact threshold	Deposit = $50,000 exactly
Timing	Valid but unusual timing	Document expires tomorrow
Format	Valid alternative format	Name with special characters
Combination	Multiple unusual-but-valid factors	Foreign national + high deposit + PEP relative
State	Unusual starting state	Customer already has 5 accounts
Sequence	Valid but uncommon path	Skip optional step

For each edge case, document:

yaml

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:

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

yaml

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:

yaml

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 Type	Example
Sequential failures	Step 2 fails, retry, Step 3 also fails
Recovery then failure	Recovered from Step 2, fails at Step 5
Parallel paths converge	Two applicants, one passes, one fails
State change mid-process	Data changes between steps
Timeout chains	Service A times out, fallback B also times out

yaml

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

yaml

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

Mistake	Why It's Wrong	Do This Instead
Generic scenarios	"Customer applies" isn't testable	Named persona with specific values
Failure without recovery	"Application rejected" - then what?	Document next steps, communication
Missing boundaries	Threshold at $50K but no $50K scenario	Test AT the threshold, not just above/below
Escalation without receiver	"Escalate to manager" - what do they do?	Define decision options and SLA
Single happy path	Real systems have multiple valid paths	One per customer type/channel
Edge = failure	Foreign national is edge, not failure	Edge is unusual-but-valid; failure is can't-proceed
No timeout scenarios	Assuming services always respond	Every integration needs timeout path

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:

•Developer test cases
•QA acceptance criteria
•Compliance evidence
•Operational runbooks