The models Huzz serves come from more than one maker. Every request must satisfy both Huzz’s Acceptable Use policy and the usage policy of the upstream provider that actually serves the request.

​
Upstream policy adherence

Provider policy enforcement is capability-aware. A request can be allowed for one model or capability and blocked for another when the selected upstream provider’s rules differ. When a provider-specific rule blocks a request, the API may return a policy error with: Provider-specific enforcement never weakens Huzz’s own policy. If Huzz policy or applicable law prohibits a request, Huzz blocks it even if an upstream provider might otherwise accept it.

​
True upstreams, not display brands

Huzz model pages and API model ids may show a branded provider name, but policy enforcement uses the true upstream route: the gateway adapter and upstream provider that receive the request. This distinction matters because multiple branded model entries can share the same upstream provider. In those cases, the same upstream policy still applies even if the visible model provider label changes.

​
Shared-upstream limitation

Some Huzz API routes can share the same true upstream even when their branded model family appears different in the catalog. In those cases, the shared upstream policy still applies to each route. Use enforced_by and routing metadata in policy errors and usage records as the source of truth for which upstream policy applied to a request.

​
No rerouting

Huzz does not reroute a request to another model or provider. A request is answered by the model it names, or refused with an error. When a provider-specific rule blocks a request, the block stands; nothing is sent elsewhere in its place.

​
Appeals

If a provider-policy block looks incorrect, include the reference_id, request capability, model id, and timestamp when contacting support or submitting an appeal. Huzz can use that id to review the selected route, true upstream and matched policy category.