How it is deployed
The public API you read about elsewhere in these docs is the same API enterprise customers use. There is no separate dialect to learn and no second set of endpoints. What changes at enterprise scale is where the models run, what is contractually committed, and how much of the operation you can see.
Three arrangements are available. Shared, where your requests run on the same pool as everyone else and you pay the published rates. Reserved, where capacity is held for you so latency does not move when the platform is busy. Dedicated, where the model runtime is deployed for you alone, in a region you choose.
The private edge
Between the API you call and the models themselves sits an internal boundary we call WAPI. Every request crosses it, and it is the only path to the model runtime. It authenticates the calling service, enforces the limits and budgets on your account before any compute is spent, and records what was spent after.
How WAPI works internally is not published. That is a deliberate position rather than an oversight: the architecture is Forlais research property. What we will commit to in writing is the behaviour that affects you. No request reaches a model without passing authentication and budget checks. No response leaves without being metered. The boundary is enforced in one place, so there is no second route that skips it.
For dedicated deployments, WAPI is the component that runs inside your boundary. Your contract names the region it runs in and who may operate it.
Isolation
| Arrangement | Compute | Latency under load | Region choice |
|---|---|---|---|
| Shared | Pooled | Varies with platform demand | No |
| Reserved | Held for you | Held to your agreement | Limited |
| Dedicated | Yours alone | Yours to plan | Yes |
Your data
Prompts and responses are not used to train EvaEsi models. That is the default on every plan, not an enterprise upgrade, and it does not depend on a setting you have to find.
Retention is yours to set. The platform holds request records for as long as you need them for your own audit and billing, and no longer. Deletion is real deletion rather than a hidden flag, and an enterprise agreement can name the window in days.
Every request carries an identifier you can trace end to end, from the call you made to the rungs you were charged. See the usage API for how to pull that record yourself rather than asking us for it.
Controls
The controls below exist on every plan. At enterprise scale they become contractual rather than best effort.
- Budgets that stop spending rather than warn about it. A hard cap refuses the request; it is never waved through because a check failed.
- Per key scoping and rotation, so a leaked key is a contained problem. See authentication.
- An audit record of who changed what in your workspace, kept separately from the request log.
- Signed webhooks for platform events, so your systems learn about budget and key changes without polling. See webhooks.
Talking to us
Reserved and dedicated arrangements are agreements rather than settings, so they start with a conversation. Tell us the request volume you expect, the latency you need to hold, the regions you are bound to, and what your auditors will ask for. We will tell you plainly whether we can commit to it.
We would rather say no to a commitment than miss one.