A rented pod answered, for a model it was serving perfectly well over its
own loopback:

    model 'datalab-to/surya-ocr-2' is not served over HTTP by this install

Not rasterisation: a PNG, which skips rasterising entirely, failed the same
way in 0.26s. The pipeline on the pod needs a LOCAL placement candidate,
where the pipeline on the orchestrator needs a POD one -- so the local path
is the one that had never run.

Two defects, and the second is why the first took all night.

1. `_model_entry_for` reads the catalogue from one place: the ConfigManager
   the admin module holds. A pod has no models.json -- its catalogue is
   seeded from CODERAI_SEED_MODELS into memory -- so any process or import
   order where that global is not that object sees an EMPTY catalogue. The
   seeded model then has no backend pin, resolves to no engine, yields no
   candidate, and the pod disowns a model it is serving. It now falls back
   to the seed list in the environment, which needs no global and no import
   order. A real catalogue entry still wins.

2. `_local_candidate` ended in `except Exception: return None`, and
   `_pod_candidate` too. Every decline now records a reason -- which of the
   catalogue entry, the backend pin or the enabled flag was missing, or the
   exception -- says it once, and clears it when the install starts working.

And the reason travels IN THE ERROR, not only in a log. The machine that
reads a pod's 503 is not the machine that can read its log; a pod's log is
not reachable from the orchestrator at all. Blaming configuration for what
may be a lookup, in the one sentence that does cross the network, is what
made this invisible.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KnfkxBpcZ1v6ypRFFyhrVM