Freehand · in development
Press one button. Say what you want.
Freehand is the interface we are building for Meridian: speak to the system on any screen and it does the work — not dictation into a notes field, but the actual operation, with your permissions applied and a confirmation step where one is warranted. It is not available today. This page is here so you can judge the direction before you decide whether to trust it.
Where this actually stands
We would rather you heard this from us. Freehand is in build. There is no interface a customer can use, and we are not giving a date, because we do not have one we would be willing to be held to.
What exists today
- The permission and confirmation model underneath it — which actions may be taken by voice, which require a confirmation, and which can never be automatic
- A per-organization and per-user setting that governs how far those rules may be relaxed, with floors that an override cannot breach
- The command pipeline it will run on, already used by the Foreman assistant: propose, stage, confirm, then write through the same guarded paths the rest of the product uses
What does not exist
- Any voice interface. Nothing in the product listens to you today.
- The on-screen control that would start it.
- A release date.
Why we think this is the right bet
Shop software has spent twenty years adding screens. The person who knows what needs to happen — the writer at the counter, the tech under the truck — spends their day translating that knowledge into navigation. Freehand is the attempt to delete the translation step, for the cases where saying it is faster than finding it.
Command, not dictation
Voice-to-text with cleanup puts words in a box; somebody still has to act on them. Freehand will carry out the operation — add the line, move the appointment, order the part — and show you what it is about to do before it does it.
Your permissions, not the assistant's
It will be able to do exactly what the person speaking is allowed to do, and nothing more. That is not a policy we intend to add later; it is the part that is already built.
A confirmation step that matches the stakes
Adding a line to an open ticket and voiding a posted invoice are not the same risk. Actions are tiered, the tier decides whether you are asked first, and the riskiest tier cannot be relaxed into silence by any setting.
Optional, forever
Off by default, on per user, and the full interface stays first-class for everyone who never turns it on. A shop where half the team prefers to click is a shop we still want.
The same work, exposed three ways
This is not a side project competing with the rest of the roadmap. Freehand, the developer interface we have committed to, and the assistant integration are one piece of work: a single catalogue of operations, each with its own permission and its own confirmation rule, routed through the same guarded write paths the product already uses.
For your developers
A documented interface your own tools will be able to call. Committed to in our Bill of Rights, and not available yet.
For the AI your team already uses
The same catalogue, reachable by assistants, with your permissions applied. Also committed to, also not built.
For the person on the screen
Freehand — the same operations, spoken instead of typed.
Building one catalogue three ways is why we think this is achievable at our size. It is also why none of the three ships before the permission model underneath them is right, which is the part we did first.
Tell us what you would say to it.
The fastest way to build the wrong thing here is to guess at the phrases. If you run a shop and want to shape this, we want the conversation — and we will tell you plainly where it stands when you ask.