Sop Builder

flowchart TD
    Start([Start Event]) --> Step1[Process Step]
    Step1 --> Decision{Decision Point?}
    Decision -->|Yes| Step2[Action A]
    Decision -->|No| Step3[Action B]
    Step2 --> End([End])
    Step3 --> End

Customer Order Information:
- Description: Details about what the customer wants to purchase
- Source: Customer via website, phone, or email
- Format: Order form with customer details, items, quantities, and delivery address
- Required: Yes
- Validation Rules: Must include valid customer contact, at least one item, and delivery address
- Example: John Smith orders 2 widgets to be delivered to 123 Main St

Logic 1: Calculate Order Discount
- Original Language: JavaScript
- Purpose: Determine the discount percentage based on order total and customer loyalty tier
- Inputs: order_total (number), customer_tier (string)
- Outputs: discount_percentage (number)
- Pseudo Python Code:
```python
def calculate_order_discount(order_total, customer_tier):
    """
    Calculate discount based on order value and customer loyalty tier.
    Business Rule: Higher tiers get better discounts, larger orders get additional discounts.
    """
    # Base discount by customer tier
    if customer_tier == "platinum":
        base_discount = 0.15  # 15% for platinum customers
    elif customer_tier == "gold":
        base_discount = 0.10  # 10% for gold customers
    elif customer_tier == "silver":
        base_discount = 0.05  # 5% for silver customers
    else:
        base_discount = 0.0   # No discount for regular customers
    
    # Additional discount for large orders
    if order_total > 1000:
        volume_discount = 0.05  # Extra 5% for orders over $1000
    elif order_total > 500:
        volume_discount = 0.02  # Extra 2% for orders over $500
    else:
        volume_discount = 0.0
    
    # Calculate total discount (capped at 25%)
    total_discount = min(base_discount + volume_discount, 0.25)
    
    return total_discount

### 6.1 LLM Prompts Documentation

If the specification contains LLM system prompts or user prompts, document them in this section.

**For each LLM prompt:**

**Prompt [Number]: [Prompt Name/Purpose]**
- **Prompt Type**: System Prompt or User Prompt
- **Purpose**: What this prompt accomplishes in business terms
- **Context**: When and where this prompt is used in the process
- **Prompt Content**: The actual prompt text (preserve formatting and structure)
- **Expected Output**: What type of response or behavior is expected
- **Variables/Placeholders**: Any dynamic elements that get substituted

**Example:**

**Note**: Only include this section if LLM prompts exist in the source specification. If no prompts are present, omit this section entirely.

### 7. Business Procedure Steps

Write the procedure as a numbered list of business steps (not technical tasks). Use clear, action-oriented language.

**Format for each step:**

**Step [Number]: [Action Name]**
- **What Happens**: Describe the business activity in plain language
- **Who Does It**: Role responsible (or "System" if automated)
- **Why**: Business reason for this step
- **Inputs**: What information is needed
- **Outputs**: What is produced or updated
- **Duration**: Typical time required
- **Success Criteria**: How to know it's done correctly

**Example:**

### 8. Decision Points

For each decision in the procedure:

**Decision [Number]: [Decision Name]**
- **Question Being Answered**: What needs to be decided?
- **Who Decides**: Role or system making the decision
- **Decision Criteria**: What factors are considered?
- **Possible Outcomes**: What are the options?
- **Business Rules**: Rules that govern this decision
- **Impact**: What happens based on each outcome?

**Example:**

### 9. Business Rules

Document all business rules that govern this procedure:

**Rule [Number]: [Rule Name]**
- **Rule Statement**: Clear statement of the rule
- **Business Rationale**: Why this rule exists
- **Applies To**: What situations or steps
- **Enforced By**: Who or what enforces it
- **Exceptions**: When this rule doesn't apply
- **Consequences**: What happens if violated

**Example:**

### 10. Exception Handling

Document what happens when things go wrong:

**Exception [Number]: [Exception Name]**
- **What Goes Wrong**: Description of the problem
- **How It's Detected**: How we know there's a problem
- **Business Impact**: What's at risk
- **Response Procedure**: What we do about it
- **Responsible Party**: Who handles it
- **Prevention**: How to avoid this in the future
- **Escalation**: When to escalate and to whom

### 10. Integration Points

Describe interactions with other systems or procedures (in business terms):

**Integration [Number]: [System/Procedure Name]**
- **Purpose**: Why we interact with this system
- **What We Send**: Information provided to the system
- **What We Receive**: Information received back
- **Timing**: When this interaction happens
- **Dependency**: What happens if this system is unavailable
- **Business Owner**: Who owns the other system/procedure

### 11. Notes and Observations

#### 11.1 Process Characteristics
Document observable characteristics from the source specification:
- Process complexity (simple, moderate, complex)
- Automation level (manual, semi-automated, fully automated)
- Integration requirements (systems involved)
- Data volume characteristics (if specified)

#### 11.2 Limitations and Constraints
Document only what is explicitly stated or observable:
- Known limitations in the current design
- Explicit constraints mentioned in the specification
- Dependencies that must be satisfied
- Scope boundaries

#### 11.3 Additional Context
Include only if explicitly provided in the source:
- Regulatory requirements (if specified)
- Compliance needs (if specified)
- Quality standards (if specified)
- Performance targets (if specified)

**Note**: If any of these elements are not defined in the source specification, state "Not explicitly defined in source specification" rather than making assumptions.

---

## Writing Guidelines

### Language and Style
- **Use Business Language**: Avoid technical jargon, BPMN terms, or automation terminology
- **Be Specific**: Use concrete examples and scenarios
- **Be Action-Oriented**: Focus on what happens and why, not how it's implemented
- **Be Clear**: Write for someone unfamiliar with the process
- **Be Concise**: Eliminate unnecessary words while maintaining clarity

### Terminology to Avoid
❌ **Don't Use**: BPMN, nodes, gateways, sequence flows, service tasks, message events, XML, JSON, Langflow components, edges, ChatInput, ChatOutput, API calls, webhooks, HTTP requests, database queries, global variables, component templates

✅ **Do Use**: Steps, decisions, activities, information, data, systems, checks, notifications, updates, records, forms, reports, inputs, outputs, configuration values

### Examples of Translation

**BPMN Technical**: "The exclusive gateway evaluates the inventory_available boolean attribute"
**Business**: "We check whether we have enough stock to fulfill the order"

**BPMN Technical**: "A service task calls the payment API endpoint with order data"
**Business**: "We process the customer's payment through our payment system"

**BPMN Technical**: "The subprocess contains embedded error boundary events"
**Business**: "If something goes wrong during this step, we have procedures to handle the problem"

**Langflow Technical**: "The ChatInput node receives user message and passes it to the ActionItemExtractor component"
**Business**: "The system receives the user's request and analyzes it to identify action items"

**Langflow Technical**: "The component template defines input_types as ['Message', 'Data', 'Text']"
**Business**: "The system accepts information in various formats including messages and structured data"

**Langflow Technical**: "The edge connects node A's output handle to node B's input handle"
**Business**: "Information flows from step A to step B"

**Langflow Technical**: "Global variable 'api_key' is configured with type 'str' and marked as required"
**Business**: "The system requires authentication credentials to access external services"

### Formatting Standards
- Use clear headings and subheadings
- Use bullet points for lists
- Use numbered lists for sequential steps
- Use tables for structured comparisons
- Use examples to illustrate complex concepts
- Use bold for emphasis on key terms
- Use quotes for specific data values or examples

---

## Quality Standards

### Completeness
- All sections must be addressed
- Sections without source information should state "Not explicitly defined in source specification"
- All decisions must have clear criteria from the source
- All data elements must be defined based on source information

### Accuracy
- Information must match the source workflow exactly
- No hallucination or invention of details
- Do NOT make assumptions - only document what is observable
- If information is inferred, clearly state "Inferred from [specific source element]"
- If information is missing, state "Not explicitly defined in source specification"

### Clarity
- Readable by non-technical business stakeholders
- Free of technical jargon
- Concrete examples provided where available in source
- Logical flow and organization

### Business Focus
- Emphasizes business value and outcomes observable in the workflow
- Explains "why" based on what can be deduced from the source
- Connects to business objectives only when evident in the source
- Addresses stakeholder concerns only when specified in the source

---

## Output Format

### File Naming Convention
`[procedure-name]-sop.md`

Example: `order-fulfillment-sop.md`

### Document Header
```markdown
# [Procedure Name] - SOP

**Document Type**: SOP
**Version**: 1.0
**Date**: [Date]
**Author**: [Name]
**Source**: [Original workflow file/diagram]
**Status**: [Draft/Review/Approved]

---

## Document Control

**Approvers**:
- Business Owner: [Name/TBD]
- Process Owner: [Name/TBD]
- Compliance: [Name/TBD]

**Review Cycle**: [Frequency]
**Next Review Date**: [Date]

---