ModelviaManaged AI

LEGAL

Service levels

There is no uptime commitment and no service credit. We would rather tell you that plainly than publish a number nobody is measuring.

Pilot terms — effective 25 September 2026

Modelvia is operated by Yo-Da Lai (ABN 84 992 526 369). These pages set out the terms and notices for the Modelvia private pilot. Questions and notices go by email to yoda@yodalai.xyz.

No availability commitment

Modelvia runs as a private pilot on a single gateway instance. A deploy, a restart, a provider outage or a fault in that one instance stops serving until it comes back. There is no second instance to take over, no failover region, and no target we are holding ourselves to.

What follows from that, concretely:

  • No uptime percentage. Not 99.9%, not any number.
  • No service credits. There is no remedy scheme attached to downtime.
  • No support response time. We answer as fast as we reasonably can; security reports are acknowledged within 2 business days, which is the only timing commitment we make.
  • No maintenance window. Deploys happen when they are ready. They are short, but they are not scheduled around you.
  • Do not build something safety-critical on this. If an outage would cause real harm, keep a fallback path in your own application.

When this becomes a committed service we will publish the commitment here, with the measurement behind it, before asking anyone to rely on it.

What is actually measured

The gateway answers two probes, and they mean different things:

GET /health
A process probe. It answers whenever the process is alive and answering, even while serving is closed, and it reports which functions are switched on. A 200 here means “the process is up”, not “your request will be served”.
GET /ready
The readiness probe. 200 means the gateway is prepared to serve; 503 means it is not, and it names the reason for the operator. It returns 503 while the instance is draining for a restart, while the single writer is being re-established, while backups are uncommissioned or the last verified backup has gone stale, or while key serving or identity is not configured.

The status page reads both of those every 30 seconds and shows the result. It is an observation, not a promise: it can only report what the probes said the last time it asked, and if the gateway is unreachable it says so rather than guessing.

How we communicate an incident

  • The status page first. It reflects the probes automatically, so it changes without anyone having to remember to update it.
  • Email to account contacts when an incident affects your account's serving, billing or data, once admission is stopped and evidence is preserved.
  • A plain account afterwards of what happened, what was affected, and what changed as a result. We do not call something resolved until the verification steps have passed — see the incident steps.
  • Ask us any time at yoda@yodalai.xyz. During the pilot there is a person on the other end, not a queue.

What we do commit to

There is no availability commitment, but three things are enforced by the system rather than by intention:

  • A refusal costs nothing. A request stopped by a cap, a rate limit or an unsupported parameter is refused before anything is reserved, and is never charged.
  • Caps refuse rather than overspend. Ceilings are applied at admission across the billing account, client, customer and project at once.
  • An interrupted request is reconciled, not replayed. A request left in an unknown state is settled against the provider's own record, so one interruption is never two charges.