Until recently this site carried a performance figure for The Align. It is gone. Not reworded — removed, from the pages, the structured data, the metadata and the machine-readable files.
This note explains why, because a product page that quietly drops a number is doing something worth being open about, and because the reasoning generalises beyond us.
What happened
We went looking for the evidence behind our own claim, in order to publish the methodology alongside it. We could not find any.
There was no test log, no comparison against a reference instrument, no error distribution, no repeatability measurement, no documented protocol. The figure existed on the website and in our marketing, and nowhere else.
The closest thing to it in our own repository was a diagnostic line printed by prototype firmware — a runtime sensor confidence value, which is the device's self-assessment of whether its own signal looks plausible. That is a health indicator. It is not a measurement of how accurately the device reports an angle, and the two are not related in a way that permits one to stand in for the other.
We cannot prove that is where the marketing number came from. We can say that no accuracy measurement exists in our records, and that is enough to require taking it down.
Why not just qualify it
The obvious middle path is to keep the number and hedge it: "measured internally", "in the current build", "not independently certified". We did that first, and then undid it.
The problem is that qualifiers do not survive contact with the world. A number gets quoted, screenshotted, pasted into a comparison, read aloud by an assistant summarising a page. The number travels; the qualifier does not. Whatever caveat sits next to it on our page is not attached to it once it leaves.
This is more true now than it used to be. Our site publishes structured data and machine-readable summaries specifically so that automated systems can read it accurately. A figure placed in that layer is designed to propagate. Putting an unsubstantiated number there and relying on adjacent prose to soften it is not a real safeguard.
And the word "measured" is itself a claim. It asserts that a measurement happened, under some method, producing some result. If we cannot produce the method or the result, we should not use the word.
The specification we also removed
The same audit turned up a second problem. We had published a sensor sampling rate.
Our own firmware history contains more than one hardware configuration, developed at different times, using different components at different settings. The number on the site matched none of the current ones, and even taken at face value it was not the figure any build actually ran at.
Underneath that sits a question we have not yet answered publicly: which configuration is the one that ships. Until we can state that, we cannot honestly publish a sampling rate, a sensor part, or a latency figure — because every one of those numbers is a property of a specific build, and quoting one from a build you are not selling is not a specification, it is a coincidence.
So those are withheld too, and will stay withheld until we can name the build they belong to.
What we changed so it cannot recur
Removing a claim once is easy. Keeping it removed, across a site that several people edit, is the actual problem.
Every measurable specification now lives in a single file with a status attached: verified and publishable, internally measured and publishable only with its methodology, or requiring data we do not yet have and therefore not publishable at all. Each entry records the file and line it was traced to.
A build step reads that file and scans every public surface — the pages, the structured data, the machine-readable summaries — for values that are not permitted. If one appears, the build fails and names the file and line. It is not a review checklist that a busy person can skip. Putting the number back breaks the site.
We tested it by reinstating the old claim deliberately. The build refused.
What has to exist before a number returns
A figure can go back on this site when we can publish, alongside it: the test rig and how the device was held, the reference instrument and its stated accuracy, the angle range and conditions, the number of trials and units, the calibration procedure, the raw data, and the formula behind the number — written out, because a bare percentage is ambiguous until you say whether it means a mean error, a proportion of readings inside a tolerance, or something else again. Each of those licenses a different claim.
Also the limitations: where it degrades, what was not tested, what the result does not establish.
That work is scheduled. Until it is done, this site says that The Align has undergone internal engineering testing during development, and does not say more than that.
What we will not claim regardless
Some things are not gated on better data, because the evidence that would support them is of a kind we have not gathered and are not currently positioned to gather.
- Clinical validation. No study measuring training or patient outcomes exists. We make no claim about either.
- Independent verification. No third party has tested this device. Any figure we ever publish will be ours, and will say so.
- Regulatory clearance. The Align is not a certified medical device and we do not present it as one.
- Diagnostic capability. It reports an orientation. It does not assess a tooth, a patient or a condition.
Why publish this at all
Partly because a site that removes a number without explanation invites a worse interpretation than the truth. Partly because the mechanism — a single source of truth with statuses, enforced by a build that fails — is a straightforward thing any small hardware team can copy, and the failure mode it prevents is common.
Mostly because for a device used near patients, we would rather be the company that publishes nothing until it can show its working than the one with the better-looking specification sheet.