> ## Documentation Index
> Fetch the complete documentation index at: https://docs.b3iq.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Route Readiness

How B3IQ explains why a machine or model is eligible or blocked for routed inference.

Route readiness explains a machine's connection, runtime, and model blockers.
For owner inference, first list models with your application's gateway key using
the [OpenAI SDK quickstart](/guides/openai-sdk-quickstart). The retained diagnostic API
below helps investigate machine state; it is not a test of that key's access.

## Machine diagnosis

For your machine's connection, runtime, and model state, sign in to
[the machine dashboard](https://b3iq.org/dashboard/nodes) and open its Models
or Health tab. A separate public-safe readiness endpoint exposes the
routing diagnosis:

```text
GET /v1/public/nodes/:node_id/route-readiness?model=<model>
```

**Owner requests and retained diagnostics**

This retained lookup does not receive your gateway key. Public explorer
  pages are retired; use your signed-in machine dashboard first. It includes policy
  diagnostics for outside work, including the owner's participation election,
  and can return a separate `promotion_blockers` list. Those findings are not
  a substitute for authenticated discovery on your own account.
  [Model readiness](/operators/model-readiness#owner-use-and-retained-promotion-fields)
  explains the promotion gates that owner inference skips. Machine health,
  installed-model matching, ownership, key restrictions, and incident controls
  still apply.

The response can include route blockers, model blockers, next actions, and
operator prompts. For `consumer_edge` profiles, `model_profiles[].consumer_edge`
reports `model_class`, a conservative `concurrency_cap`, benchmark age and
freshness, the `uptime` gates (online, tunnel ready, service persistent), recent
completions and errors with an `error_rate_pct`, the blockers, the next actions,
and an `earning_status` of `earning_ready`, `paused`, or `blocked`. It must not
include tunnel IDs, local URLs, runtime IDs, prompts, outputs, request IDs, API
keys, customer IDs, raw tokens, route secrets, or private tunnel details.

## Gate order

**Route Readiness Gates**

**Node**
  **Route**
  **Claim**
  **Model**
  **Customer**
  **liveness**
  **public route**
  **claimed**
  **eligible supply**

## Blockers and actions

| Blocker | Meaning | Operator action |
| --- | --- | --- |
| Enrollment | Node is not fully enrolled | Complete managed enrollment |
| Heartbeat | Heartbeat is stale, missing, or offline | Bring host agent online and sync a fresh heartbeat |
| Runtime | Inference is not installed, or its engine is not ready or reachable | Install inference from the machine's page in your dashboard, add an engine on its Models tab, or restart a stopped engine from Node control |
| Service persistence | The host agent is not installed as a persistent service, or does not report its persistence state | Install the host agent as a systemd service (or enable systemd linger) and let it publish a fresh heartbeat |
| Public route | The tunnel or the public inference route is missing, unhealthy, or not advertised to the router | Rotate or repair the broker-managed tunnel from the host menu, then re-publish the route in heartbeat metadata |
| Claim | Node is not linked to an owner account | Redeem the claim code from the node's setup screen in your dashboard |
| Route tier | A promotion policy rejects the tier, discovery filters it, or an incident control pauses the class | Check which policy reports the blocker. Owner chat skips economic tier gates; discovery tier filters are not an owner-chat access boundary |
| Benchmark proof | Observed benchmark evidence is missing or stale under a policy that requires it | Missing benchmark evidence alone does not block owner use. Inspect current discovery and runtime health before taking action |
| Queue health | The runtime reports a blocked or unhealthy queue; the profile gate may be skipped for owner use | Inspect runtime health and actual request results; address overload or queue failures |
| Customer policy | The key's machine/model scope rejects the request, discovery filters the model, or the profile does not support its modality, task, or capabilities | Check the intended key scope and request. Change policy only if the application should have that access |

**Earn mode withdraws a machine from routing**

A machine switched to Earn mode is excluded from every b3iq routing query at
  the SQL loader. It never appears as a candidate, so route readiness reports it
  as `route_missing` until you switch it back to Bare metal from the machine's
  dashboard page.

## The short answer

The operator-facing answer to "why is nothing routing to my machine?" should be
direct:

Owner inference needs an enrolled, online, claimed machine with a healthy
  runtime and route, an installed matching model, and account/key policy that
  permits the request. Marketplace promotion flags and benchmark evidence
  are not prerequisites for owner use. Verify discovery and a small request
  with the same key your application will use.

**Readiness is not an earnings gate**

A public readiness result does not establish earnings or access for a
  particular key. Owner inference has no per-request B3IQ charge. See
  [Claiming and earnings](/operators/earnings) for what a machine does earn from.

## Stale benchmark prompts

`benchmark.smoke` is not an operator-runnable command. Owner inference does not
require a benchmark. If a separate promotion policy reports stale observed
benchmark evidence, keep the node online
with a healthy runtime after any runtime, driver, model artifact,
quantization, context, or queue-policy change. B3IQ re-benchmarks eligible
profiles that lack fresh observed evidence on its own schedule.

## Related

**[Model readiness](/operators/model-readiness)**

Understand model profile fields and route tiers.
  **[Hosted gateway](/developers/hosted-gateway)**

See how hosted requests select eligible supply.
  **[Ownership and evidence](/protocol/overview)**

Understand account ownership, operating evidence and historical records.