Every action follows a defined blueprint before it reaches a client system.
Orbit does not decide how to accomplish a task on the fly. Every action it can take exists first as a published blueprint: a named intent, a schema defining exactly which arguments that intent accepts, the inputs that must be present before it can run, and a configured sequence of action steps that executes. If a blueprint doesn't exist for something, Orbit cannot improvise one during a call.
Published Execution Blueprints
It's 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 isn't how this works, and deliberately so. Booking an appointment, checking availability, and creating a patient record are each backed by a specific, published blueprint that existed before the call started.
The blueprint defines the operation's name, the exact shape of the data it needs, which of those fields are required versus optional, and the precise steps the system carries out once a request is approved. The model's job during a call is to gather the right inputs and select the right published intent, not to invent a path to a result that seems reasonable in the moment.
Step by step.
A blueprint has four parts, and all four are checked in order. The intent names the operation, such as "check availability" or "create patient," and only intents that have been published exist as options at all. The schema defines exactly which arguments that intent accepts and in what form, so a value outside the expected shape is rejected rather than passed through.
Required inputs are the subset of that schema that must be present and valid before the blueprint is allowed to run at all; a call missing one of them stops there. The action steps are the specific, configured operations the system performs once everything upstream has cleared, and they run the same way every time the blueprint executes. Nothing about this sequence changes based on how persuasive or confident the conversation sounds. A well-argued request against an unpublished intent still has nowhere to go.
What Orbit will not do.
Orbit cannot execute an operation that has no published blueprint, no matter how closely it resembles one that does exist.
It cannot supply arguments that don't match a blueprint's schema, and it cannot treat an optional field as satisfying a required one.
It does not chain several published steps into a new, unpublished sequence to reach an outcome faster.
If the right blueprint for a request doesn't exist, the workflow is unsupported. There is no improvised substitute.
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. Publishing blueprints ahead of time means every possible action Orbit can take was defined, scoped, and approved before any call happened, not invented during one. That's what makes it possible to say, concretely, what a given deployment can and can't do, and to know that answer won't shift based on how a particular conversation goes.
See a blueprint executed end to end.
Review how a published workflow runs against the Open Dental integration.