AlignerBot — Phase-1 to Phase-2 across Cympha, OrthoPlus, and the Agent

This walkthrough follows one case through AI clear aligner design with AlignerBot, from the Phase-1 plan and the doctor's approval or change request to Phase-2 appliance design and delivery.

Audience: A clinician submitting an AlignerBot case, the lab manager triaging it, and the AlignerBot agent operator at the lab whose Cympha Agent Manager will dispatch OrthoPlus. Read this end-to-end so each role knows what the other two are doing.

You'll come away knowing: how an AlignerBot case moves through both planning (Phase-1) and appliance design (Phase-2), where the dispatch handoffs happen, and exactly what's required when the clinician requests changes mid-loop.

Time required: Around twenty-five minutes to read. A real case typically clears Phase-1 in under an hour of agent + OrthoPlus time, plus the clinician's review wall-clock.

Before you start

You need:

A clinician with a Cympha account who can reach app.cympha.com/cases/new.
A lab on Cympha with at least one user holding the AlignerBot role on /team. Without an AlignerBot-role user, the case can be assigned to a regular designer but the agent won't auto-dispatch OrthoPlus — it will just sit as a normal designer assignment.
A Windows workstation with GuideMia OrthoPlus installed and activated, and the Cympha Agent Manager installed and paired to the AlignerBot-role user's Cympha email.
A confirmed scan set (upper + lower STL/PLY at minimum). The agent can't dispatch OrthoPlus without scans.

For the lab-side setup, walk through Set up AlignerBot for your lab first. For the agent-side, walk through Install and pair Cympha Agent Manager. If the clinician is brand new to AlignerBot, Submit an AlignerBot case is the focused intake doc.

Step 1 — Clinician submits the AlignerBot case at /cases/new

The clinician opens app.cympha.com/cases/new. They search for a lab offering AlignerBot and pick category AlignerBot. The form reveals the AlignBot params section: per-jaw plan range, automatic extraction toggle, extraction tooth numbers, missing teeth, allowed IPR, protraction/retraction, expansion, extrusion/intrusion, middle-line alignment, Spee curve, sagittal/coronal inclinations.

They upload at least the upper and lower STL/PLY. Optional: bite, photos, CBCT.

They submit. The case is promoted from draft to Submitted, held by the lab manager, who gets an email from Cympha. The full intake-side detail is in Submit an AlignerBot case.

Step 2 — Lab manager routes the case to the AlignerBot seat

The lab manager opens the new case — it shows with status Submitted and category AlignerBot. They confirm the scans and params look sane, then move the case to Designing. The status control previews who will receive the case before they commit; with an AlignerBot-seat user on the team, the case routes to that user. The full assignment walkthrough is in Assign a case to a designer.

Why the seat matters: the Cympha Agent Manager on the workstation paired to that user has an AlignerBot agent inside it. It activates only when the case's holder is an AlignerBot-seat user. If the case is held by a plain designer it stays in Designing but no automatic dispatch happens — the designer would have to drive OrthoPlus by hand.

Step 3 — Agent claims the case and dispatches OrthoPlus

On its next poll (the agent checks for new cases every 20 seconds), the Cympha Agent Manager on the AlignerBot operator's workstation sees a freshly dispatched case held by its paired user and claims a dispatch lock. (The lock keeps a second workstation paired to the same user from racing — only one agent can pick up any given design pass.)

The agent then:

Downloads the case's files (scans + any other inputs) into the workspace folder, under the case's own folder.
Launches OrthoPlus on the case in planning mode (Phase-1).

Dispatch is parallel-capable — the agent can run several OrthoPlus workers at once, configured in its Configure AlignerBot dialog.

Step 4 — OrthoPlus runs Phase-1 (planning)

OrthoPlus loads the scans, applies the AlignBot params, and runs the planning cascade. This produces a treatment plan: staged tooth positions across N steps, IPR map, attachment placements, mid-line alignment.

OrthoPlus saves its work into the case folder, including a .gvw (the Studio-viewable treatment plan). The agent uploads the .gvw automatically, and — because a review file arriving via the agent requests approval by itself — the case flips to Awaiting Approval with the Plan Approval Pending label, no lab click involved. (The .gos project file OrthoPlus works in stays local on the workstation; it isn't uploaded.) The clinician gets an email from Cympha.

Step 5 — Clinician reviews on /cases/<id>/approve

The clinician taps the email link and lands on /cases/<id>/approve. The header reads the patient name, the Awaiting Approval badge, and the step label "Approval needed — Treatment Plan".

The Files panel lists the .gvw and the original scans. The clinician clicks the .gvw link to open Studio in a new tab and orbit through the plan — staged tooth positions, attachment placement, the simulated bite at the end of treatment.

Three actions sit at the bottom:

Approve design — accept the plan.
Request changes — bounce back to the AlignerBot agent.
Escalate to lab manager — route to the lab manager.

The full approve-page walkthrough is in Approve or reject a design.

Step 6a — Clinician approves the plan → Phase-2 dispatches automatically

If the clinician approves the plan, status pivots through Approved and — because an approval cycle remains — drops straight back to Designing, with the same AlignerBot seat holding it. On the agent's next poll it claims a fresh dispatch lock.

This time the agent launches OrthoPlus in appliance mode (Phase-2), which runs the appliance-design cascade — generating what the case's Design kind calls for: Aligner models, Arch model, Bracket bonding guide, or Treatment plan only.

OrthoPlus finishes with a design-results zip and a .gos.gpk transfer pack. The agent uploads them automatically, and a .gos.gpk arriving via the agent fires the second approval by itself: status flips to Awaiting Approval again with the system label Appliance Approval Pending.

The clinician gets another email from Cympha and returns to /cases/<id>/approve. They review the appliance files and approve. Status pivots through Approved and — this being the final cycle of a digital category — advances to Delivered with no manufacturing step (see Case status glossary for the full lifecycle).

End of round trip. The case is delivered.

Step 6b — Clinician requests changes → structured artefact required

If the clinician clicks Request changes instead, the dialog asks them to confirm. For AlignerBot the dialog enforces a structured revision artefact: the confirm button stays disabled until a file with extension .xml or .gpk is already on the case.

The dialog itself surfaces an amber banner reading "Upload one of the following first:" with two paths:

An XML tooth-position file exported from Cympha Studio's 3D review. The clinician opens the case's .gvw in Studio, makes their tooth-position edits in the 3D review surface, exports an .xml, and uploads it back to the case before reconfirming the rejection.
A .gos.gpk transfer pack saved from GuideMia OrthoPlus Planner. If the clinician has OrthoPlus themselves, they can edit the plan and save it as a .gos.gpk, then upload that.

A Get the planner → link points at /downloads so the clinician can grab OrthoPlus if they don't already have it.

Once one of the two artefact types is uploaded, the Request changes confirm button enables. Clicking it flips status to Changes Requested and sends the case back to the AlignerBot seat. The agent's next poll claims a fresh lock and re-dispatches OrthoPlus in planning mode with the revision artefact applied. Phase-1 runs again with the clinician's edits baked in. The loop repeats.

Why no free-text rejection: the OrthoPlus planner cascade has no English parser. A typed instruction like "move tooth 16 buccally" has nowhere to land in the pipeline. The XML/GPK artefacts are structured inputs OrthoPlus actually consumes.

Step 6c — Clinician escalates → out of the bot loop

If the clinician clicks Escalate to lab manager, status flips to Escalated and the holder transfers to the lab manager. The bot does not re-dispatch on escalated cases. The lab manager triages — usually they review with the clinician in chat, then either send the case back through the bot (by moving it back to Designing so it routes to the AlignerBot seat) or take the case manual.

What success looks like

End state of a clean round trip:

Two approvals in the case activity log — one for the Treatment Plan step, one for the Appliance Design step.
Status Delivered on /cases/<id> (digital delivery — AlignerBot cases have no manufacturing step).
Files panel has the original scans, the Phase-1 .gvw, the Phase-2 appliance output (design-results zip and .gos.gpk), and any revision artefacts uploaded mid-loop.
The clinician's case list shows the case under Delivered, ready to be shared with the patient via Share a treatment plan with a patient.

Troubleshooting

Case sits in Designing after assignment but OrthoPlus never opens. The case is held by a designer who doesn't hold the AlignerBot seat. Move the case back through Designing so it routes to the AlignerBot-seat user — the status control previews who will receive it. The bot only activates for AlignerBot-seat holders.

OrthoPlus opens but immediately errors out loading the case. The scans are malformed or missing one jaw. Open the case in /cases/<id>, confirm both upper and lower scans are present and confirmed (not stuck mid-upload). Re-upload if needed, then click Re-run design on the case page to trigger a fresh dispatch.

Phase-1 finished but Phase-2 never dispatched after Approve. The clinician approved but the agent didn't pick the case up. Check the agent on the operator's workstation is paired. If paired but no dispatch, the case may have moved off the AlignerBot user; re-check on /cases/<id> who currently holds the case, and use Re-run design once it's back with the right holder.

Clinician's Request changes confirm stays greyed out. They haven't uploaded an .xml or .gos.gpk yet. The amber banner in the dialog explains the two valid paths. Either go to Studio's 3D review for the .xml or use OrthoPlus Planner for the .gos.gpk. Free-text instructions in case chat don't count.

Clinician wants a different design kind after approving Phase-1. The Design options card on the case page carries a Design kind selector (Aligner models, Arch model, Bracket bonding guide, Treatment plan only) plus step-range and attachment options. Saving the options doesn't dispatch anything by itself — change the kind, then click Re-run design to dispatch with the new values.

The case keeps re-dispatching Phase-1 in a loop. Check the activity log to see what's driving each pass. If the case is genuinely stuck, the lab manager can override its status from the case page and, once it's in a sane state, use Re-run design — or cancel and re-submit fresh.