AI aligner design, from proposal to refined plan
AI aligner design software runs two passes with your approval in the middle, plan first and appliance second, so you only ever review the AI's best work.
An AlignerBot case is a two-pass AI cascade through OrthoPlus, GuideMia's orthodontic software, with a clinician approval gate between the passes. Understanding the shape of the loop — what each pass does, what the gate enforces, what a refinement round actually feeds back into the planner — is what makes the whole workflow click.
Phase-1 — planning
The agent on the lab's (or GuideMia's) workstation downloads the case files and writes a short sidecar describing the case. It launches OrthoPlus in planning mode. OrthoPlus reads the scans and the intake parameters and runs the planning cascade — it computes staged tooth positions across N steps, the IPR map, attachment placements, and final-bite alignment.
OrthoPlus saves the plan as a .gos (native OrthoPlus plan) plus a .gvw (Studio-viewable treatment plan). The agent uploads both back to the case. Status flips to Awaiting Approval with the Plan Approval label and the clinician gets an email.
The approval gate
The clinician opens the case's approval page and orbits the .gvw in Studio — staged tooth positions, attachment placement, the simulated final bite. Three actions sit at the bottom:
- Approve design — advance to Phase-2.
- Request changes — feed structured edits back into Phase-1.
- Escalate to lab manager — route out of the bot loop.
Phase-2 — appliance
On approve, the case's revision counter bumps and the agent on its next poll re-launches OrthoPlus, this time in appliance mode. OrthoPlus runs the appliance cascade and produces whatever was chosen at intake — per-stage aligner shells, arch models, bracket guides, or treatment-only.
The agent uploads the appliance files. A second Awaiting Approval with the Appliance label. A second sign-off. On approve the case advances to Delivered and the round-trip is complete.
Refinement rounds are structured, not typed
The Request changes dialog will not let a clinician submit free-text instructions. The OrthoPlus planner cascade has no English parser; an instruction like "move tooth 16 buccally" has no input slot in the pipeline. The confirm button stays disabled until one of two structured artefacts is attached to the case:
- An XML tooth-position file exported from Cympha Studio's 3D review.
- A .gpk transfer pack saved from GuideMia OrthoPlus Planner.
When the artefact is uploaded, confirming flips the case to Changes Requested. The agent's next poll re-dispatches OrthoPlus in planning mode with the artefact as overlay input. Phase-1 runs again with the clinician's edits baked in. The loop repeats until both gates pass.
Where Phase-2 and Phase-3 sit today
Phase-1 planning ships today and is the focus of this chapter. The Phase-2 appliance cascade is in active development; the dispatch wiring described above is live and the contract between the agent and OrthoPlus is stable, with the appliance-design cascade rolling out in stages. A future chapter will cover Phase-3 second-round results once that loop ships.
Where this matters
- For clinicians. You only ever review structured AI output — not half-baked drafts. Two gates per case, each with a Studio review you can do in any browser.
- For labs. The cascade is the same on your own OrthoPlus workstation as on GuideMia's central one. The structured-artefact rule means refinement requests arrive as machine-consumable input, not as free-text tickets your designer has to triage.
Try it
Open app.cympha.com and submit an AlignerBot case from New Case. The full end-to-end walkthrough is on cympha.com/docs/alignerbot-phase1-to-phase2.
Part of Dental Case Lifecycle Management. Cympha runs every dental case as one tracked record — intake to outcome, across every doctor, lab, and supplier — instead of a dozen disconnected tools. What is DCLM? →