Development status

What has been shown

• ShownRecording to an encrypted store, on macOS. Audio is written to disk continuously as it is captured, encrypted as it goes, and never held in plain form.
• ShownTranscription of real appointment audio through the live EU API — eight appointments, eighty minutes. Sixteen vendor jobs created, sixteen deleted.
• ShownDental notation on real audio: sixteen corrections across those eighty minutes, sixteen of them correct, no false positives. This is the fixed rule that runs on your own machine — no model, no network call — and it is in the build you can download. Real appointments carry roughly ten times less dental vocabulary than the recordings this was designed against, so that is a smaller sample than it sounds — two of the eight contained no dental terminology at all.
• ShownThe failure drills: network loss mid-transcription, the app killed mid-recording, a recording left running by a crash, the wrong-patient guard, back-to-back appointments, a stale note after reassignment, suspend and resume.

What has not been shown

• Not shownWho was speaking, on real appointments. Before the real-audio work, none of the eight produced any role assignment; afterwards, one did — and we do not trust that one: the quiet third voice it called the patient may have been the nurse the founder’s own notes record by name. Both numbers are bad, and the second is only honest because of what it refuses. Scoring it needs a human-corrected answer key, and that key does not exist yet.
• Off by defaultThe second, model-based correction pass. A further pass over the same words, run by a service outside your computer. It is built and wired, and it runs only if you enter AWS keys in Settings; without them nothing is sent. Nothing above depends on it. Where your data goes is set out on the data protection page.
• Never producedA drafted note. No note has ever been generated by this system. The lane is built, wired into the app and red-teamed, and drafting can be started from the note screen once AWS keys are in Settings. Every attempt on our own account has so far been throttled by its daily token limit, an account setting we have asked AWS to raise. Until a real draft exists, the note preview on the main page is a drawing and says so.
• Not shownAnything at all on Windows, by a person. Both installers now build on a real Windows build server, where the type-check, the unit suite, the key-protection round-trip, the data-loss recovery screen and the sleep-mid-appointment test all run green as of 10 September. The two checks that had failed there were the tests’ own platform assumptions, not the product. Nobody has yet installed either file on a Windows machine and pressed Record.
• Shown in the wrong browserThe side panel, in Chrome itself. The build you can download starts the loopback connection the panel pairs with, so pairing works with the published files. Every panel result so far comes from Electron’s own Chromium, and nobody has yet paired the panel from a Chrome install outside this project.
• Not coveredA microphone unplugged mid-appointment. It needs a person to pull a cable. It is in the runbook and it has not been done.
• UnmeasuredA mask on and the suction running. Those are precisely the conditions that would break transcription, and we have not measured Mila in them. There is no public benchmark for a dental surgery, so the number has to come from our own recordings.
• UnmeasuredThree voices in the room. Real appointments contain a nurse, so separating speakers is a three-person problem. The recordings this was designed against were two-person.

---

The parts most likely to disappoint you

Speaker labelling asks more often than it tells

Mila is built to refuse rather than guess: where it cannot settle who was speaking, it hands the appointment back for a person to label, with everyone’s words still attached to the right voice. That is the right failure, and it is also the common one. On real appointments, most come back asking.

Part of the cause is now understood. The vendor emits labels that are not people — short artefacts of one to five turns. Those are set aside rather than merged into a real speaker, which cannot attribute one person’s words to another, but does leave a few words unattributed. The rest of the cause is that real appointments contain far less of the dental vocabulary the role mapper leans on than we assumed.

Nothing has been run on Windows

Windows is the primary target for this product and it is the least verified part of it. The installers build; nobody has installed one. If you try it, you are the first, and we would rather hear from you than have you struggle alone — the address is at the bottom of this page.

The builds are not signed

We have not bought a developer certificate. macOS will say the developer cannot be verified; Windows SmartScreen will hide the button. Nothing has vouched for those files but us, and your computer is right to say so.

Encryption protects a machine that goes astray, not software already on it

Recordings and the database are encrypted under a key held by the operating system. On macOS that key is bound to the app, and another application asking for it raises a prompt you have to approve. On Windows the equivalent is a protection interface rather than a vault: it ties the key to your Windows account on that machine, so a stolen laptop, a copied database or another person’s login cannot get at your recordings — but any program running under your own account can unseal it silently. Encryption at rest here protects your recordings from a machine or a copy of its files going astray. It does not protect them from software already running as you.

There are no backups and no restore

Mila has no sync and no export beyond copying the note out. If the practice computer dies, the recordings, transcripts and style profile go with it; the notes you have already pasted into your practice system are your record and are untouched. Restore tools are on the list. They are not here.

---

What comes next

1. The founder’s answer key, so speaker labelling can be scored against a human answer rather than described.
2. The account limit lifted, so that a first note exists and can be read by a dentist.
3. The whole setup walked through on Windows, firewall prompt included.
4. The side panel hand-loaded into Chrome stable rather than tested in the app’s own Chromium.

What would have to be true before a second practice uses this

All four of the above, plus a transcription bake-off on real dental audio against the alternatives, and a contract and data-processing agreement that do not exist yet. Those last two are set out in the data-protection note.

On today’s evidence, every one of them is open. The app is built; whether it holds up in a real surgery is the part we have not shown.

---

How this page is kept honest

Each claim here traces to a file in the project that is read next to the code: a per-item readiness checklist, an architecture note describing exactly what leaves the machine, the real-audio validation results, and a decision record for every material choice. Where those disagree with this page, they win and this page is wrong. If you want a specific figure and its source, ask — we will send the extract rather than a summary of it.