Reviewing AI aligner designs: approve, or send back an XML.

There's a quiet problem in traditional aligner workflows that almost nobody outside a lab talks about. The doctor sends a Phase-1 plan back with a request: "move tooth 8 buccally and rotate 7 mesially." The technician interprets that sentence. They move 8 buccally — but by how much? They rotate 7 mesially — but to which contact? Sometimes the interpretation matches what the doctor pictured. Sometimes it doesn't, and the next-round plan comes back wrong in a slightly different way. Each iteration introduces interpretive drift between what the doctor pictured and what the lab built.

AlignerBot's review-and-finalize loop, built into GuideMia's orthodontic software, fixes this by removing the interpretive step entirely.

What the aligner design software produces in Phase-1

The doctor submits the case; AlignerBot's agent dispatches it to OrthoPlus; the initial plan comes back as a reviewable file in the Cympha case. The case enters AWAITING_APPROVAL with approval step PLAN — meaning the doctor is being asked to sign off on the staged tooth-movement plan.

What Phase-2 actually accepts

The doctor opens the case detail and has three buttons:

• Approve — the case advances. Approval step bumps from PLAN to APPLIANCE; AlignerBot runs the appliance design (the aligner staging itself).
• Request changes — the case enters CUSTOMER_REJECTED. The case's design_revision_no increments. The agent picks up the new revision on its next poll.
• Escalate to lab manager — when the request is operational rather than design-related.

Here's the part that matters: "Request changes" accepts only one type of input — an XML refinement file exported from OrthoStudio. The system does not accept and does not process free-text instructions, comment fields, or paragraph descriptions of what to change. There is no "move tooth 8 buccally" parser. The only way to drive a Phase-2 revision is to:

1. Pull the Phase-1 plan into OrthoStudio.
2. Move the teeth where you actually want them.
3. Export the refinement XML.
4. Upload the XML to the case.

The agent picks up the new revision; OrthoPlus re-opens the original .gos (the canonical project file from Phase-1); the XML is applied as a refinement overlay; the second-round design runs automatically. No human in the redesign step.

Why the .gos stays canonical

The original .gos is the canonical source for every Phase-2 attempt. The XML is the overlay on top — a structured set of "the teeth should be here instead of there" instructions that OrthoPlus can apply machine-readably. The system explicitly does not accept a replacement .gpk as the new starting point. Every Phase-2 attempt starts from the same canonical plan, with a different overlay applied. This means revisions converge on what the doctor drew, not on what a series of technicians interpreted from a series of paragraphs.

The two approval cycles

AlignerBot runs as a two-step approval template:

1. PLAN — the initial tooth-movement plan. Doctor approves the staged setup. Approval here unlocks appliance design.
2. APPLIANCE — the aligner appliance design itself (the actual aligners). Doctor approves the appliance. Approval here advances the case to delivery.

If the doctor rejects either step, the same XML-only refinement loop runs. Different approval step, same structured-input rule.

What this changes clinically

• Revisions arrive back as exactly what you asked for. The doctor drew it; the doctor exported it; the doctor uploaded it. No interpretation gap.
• Fewer revision rounds. Convergence is faster when each round eliminates ambiguity in the request, rather than introducing new ambiguity in the response.
• The doctor's clinical reasoning travels in a viewable form. The XML overlay is the doctor's literal drawing, not a paragraph that has to be re-built.

What this changes for labs

• Phase-2 runs without a designer in the loop. XML in, redesigned plan out. The designer's time stays on cases that genuinely need design judgment.
• Throughput grows linearly with case count. No backlog from revision queues that need human interpretation.
• The lab's redesign quality is bounded by the doctor's input quality. If the doctor uploads a clean XML, the lab returns a clean redesign — without the interpretive variance that can come from passing the same paragraph to two different designers.
• Approval state is auditable per step. PLAN and APPLIANCE are separate sign-offs, recorded against the case with their own approval events.

Try it

The AlignerBot product page is at cympha.com/alignerbot. Book a walkthrough through the form below — we'll show you the Phase-1 → Phase-2 loop on a real refinement, including the OrthoStudio XML export step.

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? →