# Verification and trust

> What has to be true before a provider endpoint receives your requests, and what happens when it stops being true.

Source: https://0.0.0.0:3000/docs/routing/verification
Documentation index: https://0.0.0.0:3000/docs/llms.txt

Anyone can apply to sell inference on Numes, so no endpoint is trusted because a provider says so. An offer, one model on one endpoint at one price, receives requests only while it passes every check below. When a check lapses or fails, the offer drops out of discovery and routing until it passes again.

## Before an offer receives requests

| Check | What it confirms |
| --- | --- |
| Provider and endpoint review | Our team reviewed the operator and the endpoint before either took traffic. |
| Model name review | The public model ID was bound to the endpoint's model through platform review, not by a name match. A quantized, fine-tuned or distilled variant isn't treated as the original. |
| Price review | Prices were checked against the provider's previous prices and comparable market prices. New listings and large changes are reviewed by our team. |
| Capability verification | The endpoint can do what the offer declares. |
| Health | The endpoint is connected and ready, has room for the request, and isn't failing repeatedly. |

Activation is automatic once every check passes. Our team can't make an offer routable that hasn't passed them, and may re-review any provider, endpoint or offer at any time. Suspended and paused supply receives no requests.

## Capability verification

Automated checks exercise every capability an offer declares, such as streaming, usage reporting, tools, structured output, media and cancellation, through the same path your requests use. They use synthetic requests, never customer data.

- A pass covers the model, its connection and its tested capabilities. Our team approves a new model, a changed executable setup or added capabilities before full verification runs. Price and metadata changes reuse the pass while their own review rules still apply.
- Passes have no daily expiry. Health monitoring continues while the endpoint serves requests.
- The platform also runs additional, unannounced checks, including behavioral analysis, to confirm that endpoints serve the model they advertise.

Hosted endpoints, which the platform runs for a provider against an upstream API, take their declared capabilities from the upstream service's model information. They pass every other check above and are measured and removed from routing in the same way. See [Hosted sources](/docs/providers/hosted).

## When an offer stops passing

Health is checked for every request. If a model fails repeatedly on an endpoint, routing stops sending it requests until it passes a targeted recovery check. Failures caused by you or by the platform, such as your cancellations and invalid requests, aren't counted against the provider, and one failing model doesn't affect other models on the same endpoint.

An offer that loses its pass, keeps failing or is paused disappears from `GET /models`, the endpoints API and routing. Other endpoints of the same model keep serving. If an offer you depend on disappears, compare [`GET /models/{author}/{slug}/endpoints`](/docs/api-reference/models/list-model-endpoints) with the model's page. [Fallbacks and reliability](/docs/routing/fallbacks) covers how routing handles a failure during your request.

## What you can rely on

| You can rely on | Don't assume |
| --- | --- |
| Every serving offer passed review and meets its current eligibility checks | That an endpoint is available at any given moment |
| A model ID means the same model on every endpoint | That output in a valid format is correct |
| You're charged only for output delivered to you | That a model with one endpoint has a fallback |
| Data declarations are the provider's contractual commitments, reviewed at approval | That declarations replace your own diligence for regulated workloads |

See [Provider data policies](/docs/privacy/provider-data-policies) for what endpoints declare about your data.

## For providers

Your dashboard, terminal interface and desktop app show which check an offer is waiting on. Approved full checks have bounded automatic retries. You can retry a failed recovery check after fixing the source; further full checks require our team. See [Review and lifecycle](/docs/providers/lifecycle).

Misrepresenting a model, its capabilities, its usage or its data handling leads to suspension and to withholding or reversal of earnings.

## Next steps

:::cards
- {network} [Provider routing](/docs/routing/provider-routing) Sort, filter and pin endpoints.
- {branch} [Fallbacks and reliability](/docs/routing/fallbacks) Health, failover and model fallback.
- {lock} [Provider data policies](/docs/privacy/provider-data-policies) What endpoints declare about your data.
- {server} [Review and lifecycle](/docs/providers/lifecycle) The same checks from the provider's side.
:::