> ## Documentation Index > Fetch the complete documentation index at: https://docs.tied.com/llms.txt > Use this file to discover all available pages before exploring further. # Testing and simulation > The one way to try a flow that doesn't immediately go live, and the node types it can't simulate honestly. The simulator is a chat log you drive yourself: type what a customer might say, watch the flow respond, reset, try a different reply. It runs against the graph exactly as it sits on your canvas right now, unsaved edits included. **It's also the only way to try a flow without it immediately affecting real conversations.** As covered in [Versions and publishing](/chatbot/versions), both save controls in the builder publish — there's no "save without going live" today. If you want to see how a change behaves before it can reach a customer, the simulator is it. ## What it actually does Simulating never writes to the database and never sends anything out — no messages, no assignments, nothing to Apple's Messages platform. It's a pure, in-memory walk through the graph you hand it, plus whatever you've typed back as the "customer." Each turn returns a transcript and a status: still running, waiting on a reply, completed, or — if a run goes long — a step limit reached. ## What it simulates faithfully `send_message`, `send_amb_primitive` (rendered as a preview of the actual primitive), `wait_for_reply`, and `end` all behave the way they do in production. `branch_on_reply`'s match clauses do too — matching on the same three clause types covered in [Branching and variables](/chatbot/branching) — but its fallback diverges, and so does `assign_to_agent` — see below. ## What it doesn't **Three node types pass straight through in the simulator with no evaluation.** `conditional`, `set_conversation_attribute`, and `add_label` all run correctly for a real conversation, but the simulator doesn't evaluate a `conditional`'s branch or apply the other two's side effects — it just moves on to whatever's connected next. A flow that leans on any of these three will look simpler in the simulator than it behaves for real. **`branch_on_reply`'s fallback and `assign_to_agent` also diverge from production.** A `loop` fallback in the simulator ignores its configured `max_retries` and keeps looping until it hits the simulator's own step cap, rather than stopping at the retry count you set. An `agent` fallback just ends the simulated run instead of handing off. And `assign_to_agent` itself doesn't simulate an assignment at all — it prints a system line and nothing more. Don't read the simulator's handling of a fallback or a handoff as what a real conversation will do. **Liquid in the simulator is a stand-in, not the real thing.** It resolves flat placeholders like `{{ order_status }}` from whatever you've typed so far, but not dotted paths — `{{ contact.name }}` renders literally rather than resolving, even though it works correctly once the flow is live. Don't read a templating gap in the simulator as a bug in the flow itself. ## Step limits A single simulated turn caps at 100 node steps. Hit the cap — most likely from a `loop` fallback or a cycle in the graph — and the simulator tells you so, with a contact for raising the limit rather than failing silently. ## Where it lives The simulator is a state of the builder's side panel, not a separate page — see [Canvas basics](/chatbot/canvas) for how it shares that space with the node library and the inspector. ## Next Why there's no safe "save" outside the simulator yet. The match clauses and fallback the simulator does evaluate correctly. Opening the simulator and reading its transcript. What each node type does when it's not being simulated. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.