Verification

Verification here is bounded, and the boundary is the important part.

The two facts

A connected account carries two independent facts. They are shown as two things rather than folded into one word, because they answer different questions.

Live: does the credential work?

Refreshable. The relay probes the credential and reports:

• works: it answered a probe recently
• failing: it did not
• unchecked: no recent probe

1aile check-key     # re-probe everything
2aile check-key 3   # just account #3

This is the weaker fact. It says the credential was good a moment ago; it says nothing about whose it is.

Two refusals sharpen it for API keys:

• At link time. A key the provider's own auth check refuses outright (a 401) is refused before Aile stores it. An OpenRouter management key or an expired OpenRouter key is refused the same way, at link and on every later probe: OpenRouter's key check answers for both, yet neither can serve. A 403, a timeout or a provider error links as before, because probes fail for reasons that have nothing to do with the key.
• On a real request. When a provider answers a served request with a 401 that says the key itself is dead (not a missing scope), the account is marked failing, sorts behind every other sharer and leaves the chat catalogue. A passing key check cannot clear that mark: Check key answers refused-on-serve, because a key check can pass for a key that cannot generate. A successful serve, a passing model test or a re-link clears it.

Identity: has a provider signed for it?

Not refreshable by the sharer. Three states:

• attested: a provider signed a nonce during the link. This turns "a plausible credential" into "this sharer authenticated with the provider", and it is a claim no sharer can make about themselves.
• not-attestable: an API key can never be attested, because nothing signs a key exchange. That is an expected property of the kind of credential.
• unproven: an attestable account that has not attested yet. Re-link to fix.

Some providers support attestation (Codex today). The verdict is computed once, on the server, so aile status, aile accounts and the web dashboard cannot disagree about the same account.

In aile sharers, ✓ means attested and · means not. They are two distinct states.

Listed means tested

A third check sits per model rather than per account. A linked account's model is listed (on the market, in GET /v1/models, the catalogue and MCP find_models) only after it passes a model test: one small real request through that account, on the sharer's own quota. A caller's request no longer lists a model, and a test result does not expire; it resets when a different credential is linked on the account.

1aile models 3    # each model: listed, untested, failed, can't sell, off
2aile test 3      # test every untested model on account #3

The dashboard's Test button and MCP test_publisher_provider_models run the same test. A self-hosted model is listed once its node has answered a known-answer probe (below).

Listing is not a gate. Untested capacity still serves a caller who names it, in price order; a tested sharer goes first only at the same price. And a test proves only that the account answered a request for that model id, not which model produced the answer.

What verification does not prove

Concretely, none of the following is established by a verified badge:

• that the model named in the listing is the model that answers;
• that a self-hosted listing runs the weights it advertises;
• that answer quality matches the provider's own service;
• that a sharer will not change any of the above tomorrow.

Sharers advertise connections; Aile has not verified them. The behavioural half of this problem (canaries, evals, reputation) is designed but not built.

What evidence does exist

Passive served-model check. When a response identifies the model it came from and that contradicts what was asked for, the mismatch is reported:

1x-aile-verified: false
2x-aile-verified-model: <what the response claimed>

Emitted only on a confirmed mismatch. When it cannot be determined, the headers are silent. Absence is not evidence of a match.

Known-answer probe, self-hosted only. Local listings are probed with questions that have known answers, and the result surfaces on the listing card. A self-hosted model is listed once its node has answered one probe, right or wrong (a reply cut off at the probe's token limit, or one that only reasons, lists it too, unscored). Beyond that the probe gates nothing, feeds no trust tier, and cannot show which model produced the answer.

There is nothing equivalent for custodied capacity beyond the passive check above.

What you can do with it

Require attestation, per request:

1x-aile-verified: 1

Or browse only attested sharers:

1aile sharers --verified

Or pin the filter to a key, for clients that cannot set headers. See API keys.

The honest summary

Aile can tell you that a sharer holds the provider account they claim, and that the credential worked recently. It cannot tell you that the thing on the other end is the model on the label. Treat the badge as identity assurance.