Orbit Operating Model

When Orbit cannot safely complete a workflow, it does not pretend it did.

Workflows fail for ordinary reasons: a patient can't be found, no slot fits, a system doesn't respond in time. When that happens, Orbit reports the failure rather than papering over it with a guess or a vague reassurance that everything is being taken care of. What happens next, a retry, a stop, or a handoff to a person, depends on how that specific workflow has been configured, not on one universal rule.

What This Means

Failure and Safe Recovery

Not every call ends the way it started. A caller's information might not match anyone on file. The provider they want might have nothing open in the window they need. The practice's system might be slow, unreachable, or return something the gateway doesn't recognize as valid. None of these are exotic edge cases; they're the ordinary texture of running a phone line that talks to real, sometimes unreliable systems.

Orbit's job in that moment is narrow: recognize that the workflow can't proceed safely, say so, and hand off to whatever comes next for that specific failure, on that specific deployment. It is not to fill the gap with an answer that sounds complete.

How It Works

Step by step.

Failures are grouped by where they occur, and each is handled through the same discipline: name it and route it, rather than smooth it over. Input failures, like a missing detail the workflow needed, stop the workflow before anything is submitted anywhere. Identity failures, no match or more than one plausible match, stop patient-specific workflows at the identification step. Availability failures, no compatible slot for the requested provider or window, stop scheduling before a time is ever offered.

System failures, an unreachable connection, a timeout, or a response the gateway can't validate, stop whatever step was in progress. Configuration failures, an unpublished intent or safe mode blocking a write, stop the request at the gateway itself. In every case, what happens after the stop is defined per workflow in that client's configuration. There isn't one universal fallback that applies regardless of what failed or which deployment it happened on.

Boundaries

What Orbit will not do.

Orbit does not present an unresolved outcome as a success to avoid an awkward moment in the call.

It does not assume a single, universal escalation path applies to every failure on every deployment, since recovery behavior is configured per workflow, not fixed globally.

Human follow-up is available where a client has configured it; it is not guaranteed to trigger automatically for every kind of failure everywhere.

A failed workflow is not silently retried an unbounded number of times in the hope that it eventually succeeds.

Why It Matters

A system that hides its own failures is more dangerous than one that surfaces them, because the person on the other end of the line has no way to know something went wrong. Naming a failure plainly, and routing it to whatever recovery a client has configured, is what keeps a bad outcome from turning into an invisible one. A caller who hears that something didn't go through can call back, ask for a person, or try again. A caller who's told everything is fine, when it isn't, has no reason to do any of that.

See recovery behavior in a live deployment.

Review how failure and escalation are configured on the Open Dental integration.