A controlled gateway between Orbit and the systems each client uses.
The tool gateway is the control point between an Orbit conversation and a client's connected practice system. Orbit requests an outcome; the gateway validates the client, operation, inputs, and result before anything is treated as usable.
Orbit never talks to a client's practice-management system directly. Every action reaches Blackstar as a structured, client-scoped request and passes through a controlled gateway before it can reach a connected practice system. The gateway is the only path between a conversation and a client's connected systems. Nothing reaches a practice's software without first passing through it.
Key Facts
- Orbit does not talk directly to a practice-management system.
- Every action enters Blackstar Systems as a structured, client-scoped request.
- The gateway checks the active client, approved operation, and required inputs.
- Blocked or unsupported operations do not reach the connected system.
A conversation has to become a safe system request.
A phone conversation is unstructured. A client's practice-management system is not. Somewhere between the two, a caller's request has to become something a computer system can safely execute, and that translation cannot happen inside the model itself.
That's what the tool gateway does. When Orbit decides an action is needed, such as checking whether a Tuesday afternoon slot is open, it doesn't send that thought straight to the practice's software. It sends a structured request to Blackstar's backend first. That request is evaluated against the client's approved configuration and the operation being requested. Nothing about the underlying system, its login, or its internal structure is exposed to the conversation. The model requests an outcome; the gateway is what turns that request into something a system of record can act on, if it's allowed to.
Each request is checked before it can execute.
Before an action reaches a client system, Orbit verifies that the request belongs to the correct practice, that the requested operation is supported, and that the required inputs are valid. Only then can Blackstar send the permitted action to the connected system. The result is checked before it is treated as usable.
That boundary is consistent for every request. There is no shortcut where a request skips the gateway or reaches a client system on a different path.
Requests cannot bypass the gateway.
Orbit does not send arbitrary commands to a client's system, and it cannot request an operation that has not been approved for that client.
It cannot supply inputs outside what the approved operation allows, and it does not maintain its own direct credentials to a practice's software.
It does not skip the gateway for speed, and it does not retry a blocked request under different framing to get the same result approved.
If an operation has not been approved for a given client, the request is rejected. It does not get executed anyway because the request seemed reasonable.
Live patient and scheduling systems stay behind a review boundary.
A conversational system that could reach a practice's live software directly, with nothing in between, would mean a malformed request or a gap in judgment had nothing standing between it and a real patient record or a real appointment book. The gateway exists so every request is inspected the same way regardless of how the conversation that produced it went. It's the difference between a system that can act on a practice's data and one designed, from the ground up, to only ever act inside boundaries someone else set on purpose.
See the gateway in front of a live system.
Review how this request path plays out against the Open Dental integration.