Freehand · in development
Press one button. Say what you want.
Freehand is the interface we are building for Meridian. You will be able to press one button on any screen and say "add two hours of diagnostic time to RO 1042". It does the work, shows you what it did, and asks first when the action is risky. This is not dictation into a notes field. It is not available today either, and 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 rules underneath it: which actions may be taken by voice, which need a confirmation first, and which can never happen automatically
- A per-organization and per-user setting that governs how far those rules may be relaxed, with floors that an override cannot breach
- The machinery it will run on, already working behind the Foreman assistant: it works out what you asked for, shows it to you, waits for a yes, and then writes it the same way the rest of the product writes
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 or the tech under the truck, spends the 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, and somebody still has to act on them. Freehand will do the thing itself: add the line, move the appointment, order the part. It shows 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 nothing gets taken away from the people who never turn it on. A shop where half the team would rather 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 list of operations, each with its own permission and its own confirmation rule, written through the same checked 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 list of operations, 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 list of operations 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.