Every action follows an approved workflow before it reaches a client system.
Approved workflows are the only actions Blackstar Systems' Orbit can run, including connected-system actions such as Open Dental booking. The model gathers inputs and selects a preconfigured workflow; it does not invent a new path to book, update, route, or resolve something during the call.
Orbit does not invent new ways to act during a call. Every supported operation is defined and approved in advance, including the information it requires and the actions it is allowed to perform. If a workflow has not been configured for a deployment, Orbit cannot improvise one.
Key Facts
- Supported operations are defined before a call starts.
- Each workflow specifies required inputs and allowed actions.
- The model selects from enabled workflows instead of creating new ones.
- A reasonable-sounding request is still rejected if no approved workflow exists.
Runtime conversation does not create new capabilities.
It is tempting to picture a conversational system reasoning its way to an outcome: the caller wants an appointment, so the model figures out how to book one. That is not how this works, and deliberately so. Booking an appointment, checking availability, and creating a patient record are each backed by a specific, approved workflow that existed before the call started.
The workflow defines what information is needed, what must be valid before it can run, and what the system is allowed to do once a request is approved. The model's job during a call is to gather the right inputs and select the right approved workflow, not to invent a path to a result that seems reasonable in the moment.
Orbit selects from workflows already enabled for that deployment.
When Orbit needs to act, it selects from the workflows already enabled for that deployment. The required information is validated before anything runs, and the workflow follows its approved behavior consistently. A request cannot become a new operation simply because the conversation makes it sound reasonable.
Nothing about that boundary changes based on how persuasive or confident the conversation sounds. A well-argued request for an unsupported workflow still has nowhere to go.
Unsupported requests do not become improvised workflows.
Orbit cannot execute an operation that has no approved workflow, no matter how closely it resembles one that does exist.
It cannot supply inputs that do not match the required input format, and it cannot treat an optional detail as satisfying a required one.
It does not combine approved workflow behavior into a new, unapproved path to reach an outcome faster.
If the right workflow for a request does not exist, the workflow is unsupported. There is no improvised substitute.
Preapproved workflows make Orbit's behavior reviewable.
A system that can reason its way to new actions at runtime is also a system whose behavior is hard to predict or review in advance. Approving workflows ahead of time means every possible action Orbit can take was defined, scoped, and approved before any call happened, not invented during one. That is what makes it possible to say, concretely, what a given deployment can and cannot do, and to know that answer will not shift based on how a particular conversation goes.
See an approved workflow end to end.
Review how an approved workflow runs against the Open Dental integration.