Readiness. Reports per-module load state, so a container that answers /health but cannot actually serve inference is visible as such.

Readiness means "this module can answer", not "this module is at full strength". Every module keeps serving without its artifact — the PII detector on regex, the injection guardrail on phrases, the fraud screeners on their lexical layers, the commerce classifier by escalating everything, the document gates on geometry and optics — and failing readiness for that would take every endpoint down on a box where one build was simply never published. So a degraded module is reported, loudly, in degraded[] while the probe still passes.

Watch that list, not just the status code. A few entries are expected in it today, because labs has published no build for them: routing/language, and both documents/ gates wherever the shared OCR bundle is not installed. That is the declared state, not a fault. Every text endpoint has had a trained Indonesian model since 2026-09-21, so any of them appearing here is worth alerting on — an injection guardrail or a PII detector that lost its trained build is a security control that is nominally up and practically weaker.

The two document gates degrade differently from the rest and it is worth knowing how: without the reading bundle they cannot return accept at all, so an onboarding flow in front of them stops accepting uploads rather than accepting bad ones. That is the safe direction, and it is still an outage for whoever is onboarding.

The database block is the exception to all of that — see the comment on it below. It also carries the pool's live size and in-use count, which is the number to look at when authenticated calls start timing out for no visible reason: a saturated pool is latency everywhere and an error nowhere.

document_reading is the same kind of number for the other shared pool in this process: the OCR readers both documents/ gates check out per call. built at capacity with idle at zero means uploads are queueing behind each other inside the worker, which looks like latency on those two endpoints and nothing at all anywhere else. Raise OCR_POOL_SIZE — with MAX_WORKER_CONCURRENT_INFERENCE, never past it — or add a worker. Like database saturation it does not fail the probe, and for the same reason: it is a load signal, not a broken deployment.