Model Terms

1. Scope

These Model Terms govern your use of the AI models and inference you access through sovrgn. They apply in addition to sovrgn’s Terms of Service; where a model-specific matter is addressed here and also in the Terms of Service, these Model Terms are intended to control for that matter.

“Model output” means the content a model generates in response to your input. “Capability” means a routing alias you request (for example smart, fast, or sovereign) rather than a specific vendor model.

2. Capability routing and provider terms

You request a capability, not a specific vendor. sovrgn resolves the capability you ask for to a concrete backing model through a configuration-bound tier registry, and may fail over across more than one provider to serve your request. Providers may include Azure OpenAI, AWS Bedrock, Anthropic, OpenAI, or other OpenAI-compatible endpoints.

Because a capability resolves to an underlying provider’s model, your use of that model is also subject to that provider’s applicable terms and acceptable-use policies. sovrgn surfaces which model and region actually served each request in the response metadata (the X-Sovrgn-Model / X-Sovrgn-Region headers) rather than hiding it, so provider terms are never applied to you invisibly.

sovrgn does not represent that any capability maps to a fixed vendor; the mapping is operational and may change (see “Changes to models and availability”).

3. Input and output ownership

Policy · pending counselA proposed sovereign-aligned default — counsel confirms the final position.

Proposed position: as between you and sovrgn, you retain ownership of the inputs you submit and of the model output generated for you. sovrgn does not claim ownership of your inputs or outputs.

To operate the service, you grant sovrgn only the minimal licence needed to route, transmit, and deliver your request and its response — for example, transient processing to fulfil the request and produce the required billing metadata. sovrgn does not use this licence to build a content dataset.

Ownership and permitted use of model output may also be affected by the underlying provider’s terms and by law; you are responsible for your use of output as set out in “Accuracy and reliance”.

4. Acceptable model use and prohibited content

You must not use the models to generate, solicit, or distribute unlawful content, to harm or harass others, to attempt to defeat safety, residency, or authentication controls, to exfiltrate credentials or other users’ data, or otherwise in breach of the acceptable-use clause of the Terms of Service, which is incorporated here by reference.

The underlying providers impose their own prohibited-use rules; those also apply to your use of the resolved model. sovrgn may suspend or restrict access, and may refuse or stop serving a request, where use appears to breach these terms or a provider’s terms.

5. Residency and sovereign routing

You may pin a request to a jurisdiction (for example, au-only) using the residency header. When you do, sovrgn routes only to a model that satisfies that jurisdiction. If no in-jurisdiction model can satisfy the request, sovrgn returns a structured refusal (HTTP 403) rather than serving the request from another region. There is no silent offshore fall-through: a residency-pinned request is either served in-jurisdiction or transparently refused.

Residency is described on two axes: where the vendor resource and data-at-rest are located, and where the inference is processed. sovrgn labels a model as “sovereign” only where both the resource and the processing stay within the jurisdiction (or where the model is a designated in-country sovereign backstop). Where a model’s resource is in-region but its processing is not attested to remain in-region, sovrgn reports that honestly (for example, “at-rest” only) rather than claiming full sovereignty.

Residency labels describe routing and data-location behaviour. They are not a statement that sovrgn is a bank, an authorised deposit-taking institution, or a holder of any financial-services licence.

6. Data and model training

Policy · pending counselA proposed sovereign-aligned default — counsel confirms the final position.

Proposed position: sovrgn does not use your prompts or model outputs to train models. sovrgn operates a metadata-only posture for the routing plane — it records the operational metadata needed to route, meter, and bill a request (such as the served model, region, token counts, latency, and attribution) and does not persist your prompt or completion content for that purpose.

The underlying providers have their own positions on training and retention. Those positions also apply to your use of the resolved model; where they differ from the position above, sovrgn aims to surface the difference plainly rather than obscure it. Counsel confirms the final wording, including any provider-specific carve-outs.

7. Accuracy and reliance

Model output may be inaccurate, incomplete, or out of date, and may not reflect current facts. It is generated by automated systems and is not professional advice (including legal, financial, medical, or tax advice).

You are responsible for reviewing and verifying model output before relying on it, and for any decision you make or action you take based on it. Do not rely on output where an error could cause harm without independent verification by a qualified person.

8. Rate limits and fair use

sovrgn may apply per-caller rate limits and fair-use expectations to keep the service available and equitable for all callers. Requests that exceed a limit may be throttled or queued.

To maintain availability, sovrgn may fail a request over between providers or regions (subject to any residency constraint you set — see “Residency and sovereign routing”), and may apply circuit-breaking to an unhealthy provider. Specific limits, quotas, and any free-tier allowances are set out in the applicable plan or documentation and may change.

9. Changes to models and availability

The concrete model behind a capability may be added, upgraded, deprecated, or failed over over time, and may change without notice. Requesting a capability (rather than a specific vendor model) is what insulates your integration from those changes: you continue to ask for smart, fast, or sovereign, and sovrgn resolves it to a suitable backing model.

Availability is not guaranteed and may vary — including by residency constraint, where an in-jurisdiction model must be available for a pinned request to be served. sovrgn may modify or discontinue a capability or model; where reasonable, material changes will be communicated through the applicable channel.

10. Contact

Questions about these Model Terms or about model use through sovrgn can be raised through the contact channel on the sovrgn site. This draft will be replaced with counsel-approved text, including a formal notice address, before acceptance is required at sign-up.