define flow: joining the two

Lesson 7 named an intention and a reply, and the assistant answered from the model anyway. A flow is the statement that joins them. Three lines change both the answer and what the turn costs.

Three lines at the end of rails.co

define user ask refund policy
  "How long does a refund take?"
  "When do I get my money back?"

define bot give refund policy
  "Refunds take five working days, once the parcel is back with us."

define flow refund policy
  user ask refund policy
  bot give refund policy

Read the flow downwards: when the user's message means ask refund policy, the bot says give refund policy. The flow's own name is only a label, used in logs and in the rail listings you will meet in lesson 15.

import pretend_nemo
from nemoguardrails import LLMRails, RailsConfig

rails = LLMRails(RailsConfig.from_path("."))
print(rails.generate(messages=[{"role": "user", "content": "When do I get my money back?"}])["content"])

The exact sentence from the configuration, including the part about the parcel. No model wrote it and no model can change it.

And it is cheaper

import pretend_nemo
from nemoguardrails import LLMRails, RailsConfig

rails = LLMRails(RailsConfig.from_path("."))
for ask in ["When do I get my money back?", "Is the shop open on Sunday?"]:
    rails.generate(messages=[{"role": "user", "content": ask}])
    print(ask, [call.task for call in rails.explain().llm_calls])

One call when the flow matched, three when it did not. That difference is the most useful single fact about this runtime, and lesson 11 takes it apart.

What a flow is not

A flow is not an if on the text of the message. It runs after the runtime has decided what the message means, which is why "when do I get my money back" reaches a flow written around "how long does a refund take". This is what the documentation calls a dialog rail, and it is one of the five rail types lesson 0 listed.