Routers

A router decides where the lesson goes next. It is not a scene — students never see it. When the lesson reaches a router, the router checks its rules in order and instantly sends the student to the first destination whose rule matches. If no rule matches, the student goes to the router's Otherwise destination, so there is always somewhere to go.

Routers are how you build lessons that adapt: send strong students ahead, send struggling students to review, and break students out of a retry loop after a couple of attempts.

Create a router

Routers live on the Lesson Graph — the map of your lesson's flow, where a decision node belongs. Open the graph with ← Lesson graph at the top left of the studio, then:

• Click the orange dot on the right edge of the scene the branch starts from, then choose A router. This is the quickest way, and the one to reach for. A short guided window asks _when_ students go to the router (they tap something, they answer correctly, they answer wrong, their score is…, time runs out) — exactly the same question as adding a path — and then lets you write the router's rules and Otherwise in the next step, without leaving the window. The router arrives already connected to that scene. Its Otherwise starts on wherever the scene sent students before, so the router is never a dead end.
• Add router (in the ＋ Add scene menu above the graph) creates a router on its own, with nothing pointing at it yet. Use it when you want to build a shared hub first and wire scenes into it afterwards — until you do, the map flags it as unreachable.
• Click the router's card (its Edit rules action) — or click any of its rule arrows — to edit it: rename it (like "After the quiz"), add rules, and set destinations.
• Add rules to it. Each rule is a set of conditions plus a destination. Rules are checked top-to-bottom, and the first matching rule wins — use the arrows to reorder them.
• Read a router at a glance. Rules sit collapsed to a plain-English line of what they check and where they send students — "Cows has been visited and Pigs has been visited → Done" — so the order you'll be reading for is easy to scan. Click a rule to open it and edit its conditions and destination; click its header again to fold it back up. A rule you just added opens ready to edit.
• Set the Otherwise destination — where students go when no rule matches. Every router has one; it can't be removed.

A rule's destination can be a scene or another router, so a diagnostic router can hand off to a per-topic router. (Routers can't form a loop with no scene in between — publishing checks for that.)

Send students to a router

A router only runs when something sends the lesson to it. There are three ways:

• From the Lesson Graph — click a scene's orange dot and choose A router (above), or draw a path and pick an existing router as its destination. Either way Berdee writes the wiring for you, so this is the way to reach for.
• Scene progression — in a scene's Progression section, choose the Router mode. When the student gets the scene correct, the router picks where they go instead of a fixed destination.
• A button action — on any widget interaction, choose the Delegate to Router action. Pair it with a Submit button for a "submit, then route by result" pattern.

More than one scene can point at the same router — that is how a shared "after the quiz" decision serves every quiz scene in the lesson.

What rules can check

Rule conditions use the same building blocks as Events, Actions, and Conditions, plus a few made for routing:

• Scores — the current scene, the whole lesson, a scoring group, or any specific scene by name ("Scene score: Quiz 2 is failing"). Prefer _is passing / is failing_ over raw percentages: they respect each scene's own passing threshold.
• **Variables** — route on anything you track, like path equals "fractions" or stars is at least 3.
• Widget state — an input's value or whether a widget was answered correctly. Tip: for anything the student typed on another scene, save it to a variable first and route on the variable — variables are the reliable way to carry answers between scenes.
• Visits — whether (or how many times) a student has entered a scene or passed through a router. This is the loop-breaker: "visit count is at least 2" means _this is at least their second time here_.

The pattern to steal: a retry loop that doesn't trap anyone

1. Quiz scene → Progression mode Router → "After the quiz".
2. Rule 1: Visits: After the quiz — visit count is at least 3 → "See the teacher" scene. _(Checked first, so it wins on the third failure.)_
3. Rule 2: Current scene is passing → the next lesson section.
4. Otherwise → the review scene, which ends with a button back to the quiz.

Strong students pass straight through. Struggling students get the review — but never forever, because rule 1 catches the third arrival and routes them somewhere kinder.

Another pattern: finish only after exploring every part

Give every part of an explore-in-any-order lesson the same Back to the map button, and send each one to one router. Rule 1 checks Visits: Part A has been visited, Visits: Part B has been visited and so on, with All conditions are met, and goes to the ending; Otherwise goes back to the map. A visit counts the moment a student arrives on a scene, so the last part's Back button is the one that opens the ending. Step-by-step: Finish the lesson only after students explore every part.

Good to know

• Rules are checked against the student's state at the moment they hit the router — one snapshot, top to bottom, first match wins.
• A rule with no conditions always matches, so any rules below it can never win. The publish check warns you about this.
• The Lesson Graph draws every router as an amber card with one labeled arrow per rule plus the Otherwise arrow — the fastest way to sanity-check your branching before assigning.
• Deleting a scene or router that a rule points at blocks publishing until you pick a new destination, so a broken path can never reach students. The Lesson Graph shows the dangling rule as a missing arrow so you can find and fix it.
• Deleting a scene or widget that a rule's _condition_ checks blocks publishing too, not just its destination — a rule that can never be evaluated is just as broken as one that leads nowhere.
• If a rule checks a dropdown's selected value or a spin wheel's last segment, renaming or deleting that option matters: an equals rule blocks publishing (it can never match again), and a does not equal rule gets a warning (it becomes always true, so it stops filtering anything). See Renaming an option a condition points at.