# What Triggers AI-DLC User Story Inclusion: Priority Rules and Assessment Criteria

> Learn what triggers AI-DLC user story inclusion in AWS workflows. Discover priority rules and assessment criteria for user-facing features, API changes, and complex logic.

- Repository: [Amazon Web Services - Labs/aidlc-workflows](https://github.com/awslabs/aidlc-workflows)
- Tags: how-to-guide
- Published: 2026-05-09

---

**AI-DLC includes the User-Stories phase during the Inception workflow when the requested change involves user-facing features, API changes, or complex business logic, while skipping it for internal refactoring or isolated bug fixes.**

The AI-DLC (AI-Driven Development Lifecycle) framework from the `awslabs/aidlc-workflows` repository uses an intelligent assessment system to determine whether the **User-Stories** stage should execute. This decision happens in the Inception phase and is governed by rules defined in [`aidlc-rules/aws-aidlc-rule-details/inception/user-stories.md`](https://github.com/awslabs/aidlc-workflows/blob/main/aidlc-rules/aws-aidlc-rule-details/inception/user-stories.md). Rather than running uniformly for every request, the system categorizes changes into priority tiers that dictate whether user stories are mandatory, conditional, or unnecessary.

## High-Priority Triggers (Always Execute)

When a request falls into specific high-impact categories, AI-DLC **requires** the User-Stories stage without exception. According to the assessment rules in the repository, these triggers include:

- **New user-facing features** that introduce functionality visible to end users
- **UX changes to existing flows** that alter how users interact with the system
- **Multi-persona systems** supporting distinct user types (e.g., admin vs. customer)
- **Customer-facing APIs** that expose functionality to external consumers
- **Complex business logic** involving multiple scenarios or decision branches
- **Cross-team projects** requiring shared understanding between multiple groups

If any of these conditions evaluate to true, the system automatically proceeds to the Story Generation checklist defined in [`aidlc-docs/inception/plans/story-generation-plan.md`](https://github.com/awslabs/aidlc-workflows/blob/main/aidlc-docs/inception/plans/story-generation-plan.md).

## Medium-Priority Triggers (Complexity-Based Inclusion)

For requests that are not obviously user-facing—such as performance improvements, security changes, or data migrations—AI-DLC applies a **complexity assessment**. The User-Stories stage runs only when the change is internal-facing **and** at least one complexity factor applies:

- Scope spans **multiple components** or **user touch-points**
- Requirements are **ambiguous** or require stakeholder clarification
- **High business risk** or significant financial/operational impact
- **Multiple stakeholders** are involved in approval or validation
- **User-acceptance testing (UAT)** will be required for validation
- **Multiple valid implementation approaches** exist, requiring architectural decisions

This logic ensures that backend changes with broad impact still receive proper user-story definition, while simple optimizations bypass the overhead.

## When AI-DLC Skips User Stories

The framework explicitly **excludes** the User-Stories stage for changes with zero user impact. According to the rules in [`aidlc-rules/aws-aidlc-rule-details/inception/user-stories.md`](https://github.com/awslabs/aidlc-workflows/blob/main/aidlc-rules/aws-aidlc-rule-details/inception/user-stories.md), the following categories bypass the phase:

- **Pure refactoring** or code-style cleanup that preserves behavior
- **Isolated bug fixes** with clearly defined scope and no interface changes
- **Infrastructure-only changes** such as CI/CD pipeline updates or deployment configs
- **Development-tooling updates** affecting only the engineering workflow
- **Documentation edits** that do not modify functionality

The assessment logic treats these as "simple cases" where the cost of story creation outweighs the value.

## Default Rule for Ambiguous Cases

When the high, medium, and simple checks return inconclusive results, AI-DLC applies a **conservative default**: it **includes** the User-Stories stage and prompts the user for clarification. This default rule reflects the framework's design philosophy that the cost of additional story work is usually outweighed by the benefits of clearer requirements, better testing criteria, and reduced rework.

The decision and rationale are recorded in [`aidlc-docs/inception/plans/user-stories-assessment.md`](https://github.com/awslabs/aidlc-workflows/blob/main/aidlc-docs/inception/plans/user-stories-assessment.md), creating an audit trail for why the phase was or was not executed.

## Assessment Implementation and Workflow Integration

The trigger mechanism is implemented across several interconnected files in the `awslabs/aidlc-workflows` repository:

| File | Purpose |
|------|---------|
| [`aidlc-rules/aws-aidlc-rule-details/inception/user-stories.md`](https://github.com/awslabs/aidlc-workflows/blob/main/aidlc-rules/aws-aidlc-rule-details/inception/user-stories.md) | Defines the priority criteria and assessment matrix |
| [`aidlc-rules/aws-aidlc-rule-details/inception/workspace-detection.md`](https://github.com/awslabs/aidlc-workflows/blob/main/aidlc-rules/aws-aidlc-rule-details/inception/workspace-detection.md) | Determines when the Inception workflow (including User-Stories) is entered |
| [`aidlc-rules/aws-aidlc-rule-details/inception/workflow-planning.md`](https://github.com/awslabs/aidlc-workflows/blob/main/aidlc-rules/aws-aidlc-rule-details/inception/workflow-planning.md) | Orchestrates planning and invokes the User-Stories assessment |
| [`aidlc-docs/inception/plans/user-stories-assessment.md`](https://github.com/awslabs/aidlc-workflows/blob/main/aidlc-docs/inception/plans/user-stories-assessment.md) | Runtime artifact recording the specific decision for a request |
| [`aidlc-docs/inception/plans/story-generation-plan.md`](https://github.com/awslabs/aidlc-workflows/blob/main/aidlc-docs/inception/plans/story-generation-plan.md) | Checklist executed only when User-Stories is enabled |

### Decision Logic Example

The following pseudo-code from the repository illustrates how the framework evaluates triggers:

```python
def should_run_user_stories(request):
    # High-priority triggers (always execute)

    high_priority = any([
        request.is_new_user_feature,
        request.is_ux_change,
        request.has_multiple_personas,
        request.is_customer_facing_api,
        request.is_complex_business_logic,
        request.is_cross_team
    ])
    if high_priority:
        return True

    # Medium-priority – evaluate complexity factors

    medium_factors = any([
        request.spans_multiple_components,
        request.is_ambiguous,
        request.has_high_risk,
        request.involves_multiple_stakeholders,
        request.requires_uat,
        request.has_multiple_implementation_options
    ])
    if request.is_backend_user_impact or request.is_perf_improvement \
       or request.is_integration or request.is_data_change \
       or request.is_security_change:
        return medium_factors

    # Simple cases – skip

    simple_cases = any([
        request.is_pure_refactor,
        request.is_isolated_bug_fix,
        request.is_infra_only,
        request.is_dev_tooling,
        request.is_doc_only
    ])
    return not simple_cases   # include only if not a simple case

```

### Assessment Template

When the phase is triggered, the framework generates an assessment document using this template structure defined at lines 94–112 of [`user-stories.md`](https://github.com/awslabs/aidlc-workflows/blob/main/user-stories.md):

```markdown

# User Stories Assessment

## Request Analysis

- **Original Request**: <summary>
- **User Impact**: Direct / Indirect / None
- **Complexity Level**: Simple / Medium / Complex
- **Stakeholders**: <list>

## Assessment Criteria Met

- [ ] High Priority: <list applicable items>
- [ ] Medium Priority: <list factors that justify execution>
- [ ] Benefits: <expected value from user stories>

## Decision

**Execute User Stories**: Yes / No  
**Reasoning**: <detailed justification>

```

## Summary

- **AI-DLC user story inclusion** is triggered by an intelligent assessment during the Inception phase that categorizes requests into high-priority (always), medium-priority (complexity-dependent), or simple (skip).
- **High-priority triggers** include new user features, UX changes, multi-persona systems, customer-facing APIs, and cross-team projects.
- **Medium-priority triggers** apply to internal changes that span multiple components, involve ambiguous requirements, carry high business risk, or require UAT.
- **Simple cases** like pure refactoring, isolated bug fixes, infrastructure updates, and documentation-only changes skip the User-Stories stage entirely.
- The default rule includes the phase when uncertainty exists, recording the decision in [`aidlc-docs/inception/plans/user-stories-assessment.md`](https://github.com/awslabs/aidlc-workflows/blob/main/aidlc-docs/inception/plans/user-stories-assessment.md).

## Frequently Asked Questions

### What file contains the rules for AI-DLC user story inclusion?

The assessment criteria are defined in [`aidlc-rules/aws-aidlc-rule-details/inception/user-stories.md`](https://github.com/awslabs/aidlc-workflows/blob/main/aidlc-rules/aws-aidlc-rule-details/inception/user-stories.md) within the `awslabs/aidlc-workflows` repository. This file specifies the high-priority categories, complexity factors, and simple-case exemptions that determine whether the User-Stories stage executes.

### Does AI-DLC always generate user stories for new features?

Yes. **New user-facing features** are classified as high-priority triggers that always require the User-Stories stage. This ensures that feature requirements are captured, acceptance criteria are defined, and testing scenarios are documented before implementation begins.

### Can internal performance improvements skip the user stories phase?

They can, but only if they lack complexity factors. According to the rules in `aidlc-rules/aws-``[`aidlc-rule-details/inception/user-stories.md`](https://github.com/awslabs/aidlc-workflows/blob/main/aidlc-rule-details/inception/user-stories.md), performance improvements bypass user stories only when they do **not** span multiple components, involve ambiguous requirements, or require user-acceptance testing. If any complexity factor applies, the stage is included.

### What happens if the assessment is inconclusive?

When the framework cannot definitively classify a request into high, medium, or simple categories, it applies a **default inclusion rule**. AI-DLC executes the User-Stories stage and prompts for clarification, ensuring that potentially complex changes do not proceed without proper requirement definition.