Platform thesis
What makes Cympha better
Not a claim about being ahead — a description of how the system is put together, and what that construction makes possible that a folder of files cannot.
Three things carry it: an AI orchestrator that schedules tasks and holders instead of moving files between people, AI agents that take work under exactly the same contract a person does, and a hybrid human-AI environment in which confidence and policy decide what a machine is allowed to do on its own. Each one is a mechanism you can check, and each produces a consequence that is hard to reach any other way. The engineering behind them is set out in the companion architecture paper; this one is the reasoning. The claims it makes are checked against a sourced comparison of eight case platforms, and each one below links to the criterion it rests on.
Start with the comparison
Before the reasoning, the evidence. 8 dental lab and clinic case platforms were read against 57 criteria in 4 product areas, every value cited to the page it came from. Cympha's column is read from its source code; every other column from what that vendor publishes, and the asymmetry is marked on each cell.
- 17
- criteria with three or more systems documented
- 10
- with one or two documented
- 14
- where only Cympha's documentation answers
- 16
- baseline: every system does this
All 57 criteria are on the comparison page, with 239 cells named as not established rather than left blank. No cell claims an absence nobody tested for.
Systems compared: Cympha · Evident / EviSmart · TrazaLab · Magic Touch Signature · Labtrac · 3Shape LMS / Unite · Medit Link · Dandy
What the comparison settles
Who can use it alone. Four architectures appear in the table. Lab-side management systems issue a portal to the lab's own dentists. Scanner vendors' platforms tie the clinic side to the scanner. A single-vendor laboratory fixes the lab. In Cympha a practice runs its own cases with no lab assigned, a lab runs the cases it enters itself, and a case joins the two when a lab is chosen for it.
What it is built on. The technology row records what each vendor states and what its sign-in page serves. Cympha is a browser application for the portal and for Studio, with the desktop agents as optional Windows automation. Two systems in the table are installed applications with a sync step between the desktop and the cloud, and the table cites the vendor's own support articles on what that step does when it fails.
How a scan reaches the portal. A scanner vendor routes its own scanner into its own portal. Where scanner and portal come from different vendors, the lab-management systems pull orders out of the scanner vendors' portals through connectors they maintain. The Cympha Agent's File Monitor watches the folder the scanner exports to, which covers any scanner that writes a file, and Cloud Monitor keeps a workspace folder current with no browser open.
Sharing with someone who has no account. Three systems open a shared case in a browser without a sign-in: Cympha, Medit Link's Case Talk and 3Shape Communicate. Cympha's share records the view count and the recipient's receipt and can require an account at download; the Medit link expires in up to 90 days with download and comment permissions set per share.
Where the processing runs. CBCT segmentation runs on the operator's own machine: the agent downloads the pipeline once, runs it against the DICOM folder and writes the output locally, so the volume stays in the building. The one competitor that documents comparable modules delivers them as a cloud platform.
What the 3D workspace does. Of the 9 Studio criteria, 5 are answered only by Cympha's documentation: opening and re-packing the planner's native case files, mesh repair, measurement and deviation maps, aligner staging, occlusion simulation, facial scan and smile design, cephalometric tracing, and the techniques Studio uses to stay fast. The other viewers in the table open an exported mesh to rotate, zoom and approve. That silence is a question about them, and the cards put it that way.
The thing being managed is a case, not a folder
Digital dentistry runs on islands. Scanners, design programs, messengers, clouds, outside designers — each one works, and none of them knows the others exist. The usual response is a portal that moves files between the islands, and it inherits the shape of what it moves: it manages folders and tickets.
A dental case is more than its files. It has five dimensions, and software that keeps only the first one leaves the other four to be carried by people, in email, on the phone, and in memory.
- 3D. The case has a shape. Real scans, models and designs, seen and worked in three dimensions rather than inferred from a file name.
- Timeline. The case has a life — intake, design, review, delivery, and on into follow-up. One current version, a full history, and a case that does not end the moment the box ships.
- Dialogue. The case is a conversation. Doctor, lab, designer and patient on one thread, attached to the case rather than scattered across separate email chains.
- Intent. The case has a goal. The doctor's intent is captured on the lab's own order form, carried to whoever designs it, and checked against the result.
- People. The case has a team — staff and agents working it together, at any size, from anywhere.
Everything below follows from treating those five as one record. The mechanisms are what make that record run itself rather than sit there being updated by hand.
One: the AI orchestrator
The orchestrator schedules tasks and holders. It does not walk a case through a state machine, pushing one object from status to status; it works out what task is ready, who or what can hold it, and hands it over.
The load-bearing detail is that a subtask carries its own context and its own deliverable definition. A task is not a pointer back to the case saying "look here for what you need" — it carries what is needed to do it and what counts as done.
That single property produces the consequence that matters most in practice:
Assigning work inside your organisation and subcontracting it outside are the same call, not two mechanisms.
For a lab, that is the whole outsourcing question answered structurally. Sending an overflow case to a freelance designer is not a special mode, an export, or a second system to keep in step. It is the same assignment, to a different holder. The case does not leave the record to go outside and come back; the task goes out, and the deliverable returns to the case it belongs to. Nothing has to be reconciled afterwards, because nothing was ever copied.
The same property is why a doctor you work with does not need an account to be part of a case, and why a specialist can be brought in for one question without anybody being set up first. Participation is a holder on a task, not a seat in a system. It is also why a practice or a lab can start alone: a practice runs its own cases with no lab assigned, a lab runs the cases it enters itself, and the two join when a lab is chosen for a case.
Two: AI agents, under the same contract as people
There are three kinds of agent, and they are different in what they do, not in how they are governed:
- Design agents — they produce a design. AlignerBot, GuideMia's OrthoPlus automation, takes an aligner case and returns a plan and an appliance design.
- File-handling agents — they move work between the case and the place it is done. The Cympha Agent puts a workstation inside the case: assigned cases land on disk and finished work uploads back, and a scanner or CBCT export folder becomes a new case, whatever brand wrote the files.
- AI model agents — they run a model over the data. CBCT segmentation runs on the workstation itself, so the volume stays in the building.
All three, and people, share one task contract: claim, lock, return, adjudicate. That is not a figure of speech about teamwork. An agent holds a role in the system and is assigned work the way a member of staff is, is recorded on the case the way a member of staff is, and returns a result that is adjudicated the way a person's is.
Two things follow. The first is that work routes to whoever is free without anyone deciding in advance whether that will be a person or a machine — capacity is capacity. The second is that adding a new executor is a plug-in module rather than an integration project, because the thing being added only has to accept a task and return a result.
Three: a hybrid human-AI environment
The hard part of putting AI inside real work is not getting a model to produce an answer. It is deciding what the system may do with an answer nobody has looked at yet. Most software answers this once, globally, and the answer is either "nothing" — in which case the automation saves no time — or "everything", which no lab will accept.
Cympha answers it per organisation and per kind of change, through a proposal. A proposal is a superset of a change order: besides what it wants to change, it carries a confidence, so a machine can propose honestly rather than assert. Alongside it sits a policy, which the organisation sets:
| Knob | What it decides |
|---|---|
| Kind of change | Policy is set per kind, so a routine file move and a clinical decision need not share a rule |
| Auto-apply | Whether this kind may ever be applied without a person |
| Minimum confidence | How sure the proposer must be before it may act alone |
| Daily cap | How many it may apply in a day, so a bad run is bounded rather than discovered later |
Each proposal also records why it was raised — the event that triggered it — so the tray can say what happened and not merely what is suggested.
Two design decisions make this honest rather than decorative. A proposal that is auto-applied is flagged as such, so it can always be told apart in an audit from one a person approved. And a human is still recorded as the responsible actor, so accountability has a name on it rather than dissolving into "the system did it".
This is what "hybrid" means here: not people and AI in the same product, but people and AI doing the same work under one set of rules, with the organisation holding the dial.
What sits underneath: one record, two geometries
None of the three works without a record worth orchestrating. Two properties of that record matter enough to state.
Mesh and CAD are equal representations. A scanned mesh and an exact boundary representation are both first-class. Representation is an attribute of the geometry, not a fork in the schema, so versioning, where-used and permissions behave identically for each. In dentistry this is not a nicety: a case routinely contains both, and a system that treats one as the real data and the other as an attachment will lose half of every case. It is also what lets Studio open, edit and re-pack the planner's native case files in the browser, where the other viewers in the comparison open an exported mesh to rotate and approve.
Files land once. The case holds one copy, reached from anywhere, shared by link. Anyone you share with can read, download and reply without a subscription; the sender sees the view count and the recipient's receipt is recorded. Nothing is re-sent, so there is no question of which copy is current — there is only one.
The browser does the work. Studio is where the record is handled, and mesh repair, measurement and deviation maps, aligner staging, occlusion simulation, facial scan and smile design and cephalometric tracing run there, with the heavy computation in WebAssembly and web workers. Nothing is installed for the portal or for Studio; the desktop agents are optional automation on Windows.
Four categories, one system
Because the record is the case rather than the file, Cympha fills several roles that are normally bought as separate products. Each is a working software category in its own right, and the same record serves all four:
| Read as | What it does in that role |
|---|---|
| Dental case management | The case as one record crossing clinic and lab, carrying intent, status and approvals |
| Dental lab management | Case data arriving in any format, transformed for the bench, and routed to the right person |
| Dental cloud | Files that land once: storage, sharing without accounts, and the desktop bridged by the Agent |
| Dental AI | AI assigned work inside the case, with a person approving every result |
They are not four products with a shared login. They are four readings of one record, which is why a lab does not have to decide in advance which one it is buying, and why work does not have to be reconciled between them afterwards.
What it adds up to
The mechanisms are chosen, not accumulated, and each one answers a question that a file-shaped system cannot:
| Mechanism | What becomes possible |
|---|---|
| Orchestrator — tasks and holders | Outsourcing is an assignment, not an export. Participation needs no account. |
| Agents under one contract | Capacity is capacity. A new executor is a module, not a project. |
| Confidence and policy | Automation you can turn up a notch at a time, and audit afterwards. |
| One record, two geometries | Nothing is re-sent, and no half of a case is a second-class attachment. |
You can start with whoever you already work with. A lab alone, a practice alone, or both together — the others join when they want to, because nothing requires them to be there first.
Everything above that names a capability is a row in the comparison, with its source beside it and the systems it could not be established for named on the card. Where a lab-management system documents something Cympha does not — carrier integration, inventory, an accounting link — the table says so in Cympha's own column.