Understanding RASA pipelines

Our previous blog: Understanding YAML describes how RASA NLU handles entities, intents and how slots are used within RASA.

This blog will discuss the need and use of stories, rules, policies, and forms within a chatbot.

Contents of this blog:

• Stories
• Rules
• Policies
• Forms

So, What are stories?

Stories

If intents describe what the user wants, entities describe the details, and slots describe what the assistant remembers, then stories describe how a conversation flows over time. In simple terms, stories teach RASA what should happen next. They are examples of conversations written from start to finish, showing how the assistant should respond given a sequence of user inputs, slot values, and actions.

Why stories exist
Unlike rule-based chatbots that follow rigid decision trees, RASA learns dialogue behaviour from examples. Stories provide those examples. Instead of explicitly coding:

If the user says X, then do Y

The programmer shows RASA:

When conversations look like this, the assistant usually responds like that.

What a story contains?
A story is a sequence of: User intents, Optional entities and slot updates, and Assistant actions written chronologically.

Essentially stories are training sets which train the bot on a set behaviour for some branch of the conversation.

User says something
→ Bot responds
→ User provides more info
→ Bot reacts accordingly

This sequence is what RASA learns from.

Basic story structure
Stories are defined in stories.yml.

version: "3.1"

stories:
- story: report symptom with duration
  steps:
  - intent: report_symptom
    entities:
    - symptom: fever
  - action: action_ask_duration
  - intent: provide_duration
    entities:
    - duration: three days
  - action: action_give_advice

Each step represents one turn in the conversation. This provides the programmer the ability to be as nuanced or intentional as they want to be with their respective bot, and conversation direction.

However, to be careful so that the bot doesn't respond to the unintended queries, we implement rules.

Rules

If stories teach RASA how conversations usually flow, rules define what must always happen. Rules are used when there is no room for ambiguity. They ensure that certain behaviors are deterministic, predictable, and enforced, regardless of context, wording, or conversation history.

Why rules exist

Machine learning is probabilistic by nature. That’s great for flexible conversations, but dangerous when a set condition is required to occur.

• A goodbye should always end the conversation.
• A form must always ask missing information.
• An emergency symptom must always escalate.

Rules act as guardrails that override uncertainty within response selection, adding deterministic behaviour within the responses.

What a rule contains
A rule describes two important properties of behaviour:

1. A condition (intent, slot, or active loop)
2. A mandatory action that must follow

Unlike stories which preserve possible probabilistic behaviour, rules do not branch, they do not generalise and are applied without any variation to them.

Basic rule structure
A basic rule structure consists of the name of the rule, and the steps which are to be carried out by that rule.

version: "3.1"

rules:
- rule: say goodbye
  steps:
  - intent: goodbye
  - action: utter_goodbye

Rules can also depend on slots or conversation state, hence certain conditions must be met surely in order for rules to be executed.

- rule: emergency escalation
  condition:
  - slot_was_set:
    - emergency: true
  steps:
  - action: action_emergency_protocol

When both rules and stories apply to a conversation, we follow a rule first order, hence if a rule exists, RASA will follow it even if a story suggests a different response.

Policies
If intents and entities help RASA understand what the user said, and stories and rules describe how conversations should flow, then policies decide which action the assistant should take next.
Policies are the decision-makers of RASA’s dialogue system. A policy is a strategy that RASA uses to predict the next action based on:

• The current conversation state
• The intent detected
• Extracted entities
• Slot values
• Previous actions
• Active rules or forms

Multiple policies can exist at once, and RASA evaluates all of them before choosing the final action. Within the architecture of information processing, policies are located as after considering the conversation state.

User message
   |
   V
NLU (intent + entities)
   |
   V
Tracker (conversation state)
   |
   V
Policies evaluate state
   |
   V
Best next action chosen

Policies operate after NLU and before response execution.

Each policy:

1. Looks at the conversation tracker
2. Predicts the next action
3. Assigns a confidence score

RASA then selects the action with the highest confidence across all policies. A typical config.yml might look like:

policies:
  - name: RulePolicy
  - name: MemoizationPolicy
  - name: TEDPolicy

RulePolicy

The RulePolicy enforces rules. It checks if any rule applies, If yes → executes the rule-defined action it overrides all other policies. This guarantees deterministic behavior. If a rule matches, no ML prediction is needed.

MemoizationPolicy
Memoization is exact recall. If the current conversation state exactly matches a previously seen story, RASA repeats the same next action.

TEDPolicy
The TEDPolicy is RASA’s main ML-based dialogue policy. It embeds conversation states, learns patterns across stories, and generalises to unseen paths.

TED allows the assistant to handle paraphrases, adapt to partial information, manage complex, and branching conversations.

When it comes to how RASA NLU processes policies, it follows the conceptual order. So in our example, it would be RulePolicy -> deterministic manner, MemoizationPolicy -> Trained/seen data and follows it up using TEDPolicy to hand it off to ML processing.

Forms

If intents tell RASA what the user wants, entities extract key information, and policies decide what to do next, then forms exist to systematically collect missing information.
Forms are RASA’s way of saying:
I can’t proceed until I have everything I need.

A form is a controlled dialogue mechanism used to:

• Ask the user for required information
• Validate inputs
• Store values in slots
• Maintain conversational context until completion

They exist to handle free-flow conversation breaks down when:

1. Multiple values are required
2. Order matters
3. Missing data blocks progress

In our previous pipeline, forms act right after intent and entity consideration

User message
   |
   V
Intent + Entities
   |
   V
Form activated
   |
   V
Ask for required slots
   |
   V
Validate inputs
   |
   V
Form deactivates

Defining a form
Forms are declared in domain.yml in the following manner:

forms:
  symptom_form:
    required_slots:
      - symptom
      - duration
      - severity

When a required slot is empty, RASA automatically asks for it when forms are activated in stories and rules.
This covers up the basics of using RASA to build a chatbot, finally we will begin diving deeper into how the chatbot files play off each other and are used to, how policies themselves work, and intentional actions.

The next blog: To be released