Liveness Is Not Model Readiness

“Healthy” can refer to more than one state. In the Fashion Attribute Recognition API, the repository documents three endpoints that describe different parts of service state: `/health/live`, `/health`, and `/health/ready`.

The README calls `/health/live` a process-liveness check. At the inspected commit, the handler returns `status: ok` and includes `model_loaded` and `model_version`; its response does not change based on the loaded flag. One detail matters when reading that behavior: the handler obtains a cached model-service object, and creating that object runs artifact validation. The endpoint's response is still `ok` when the model is not loaded, but its first call is not entirely separate from service initialization.

The `/health` response communicates a different state. Its handler returns `ok` when the model is loaded and `warming` otherwise. That field provides a direct signal that a liveness response alone does not carry.

The `/health/ready` handler first checks the artifact validator's readiness state. If artifacts do not validate, it returns HTTP 503. If they pass, the handler calls the model loader and then returns `status: ok` with the `model_loaded` flag. A loader exception follows the generic exception handler and becomes HTTP 500. The route does not explicitly assert the loaded flag after the load call returns, so the response contract includes both the code path and the returned flag.

The artifact validator checks the configured metadata and manifest, checkpoint, local DINOv2 directory when required, label maps, required artifact paths, and recorded file hashes. Those checks address whether specified runtime artifacts are present and consistent. They do not measure whether predictions are accurate, calibrated, robust to different image distributions, or useful for a particular decision.

The repository includes a test that expects `/health/live` to return 200 and a test that expects readiness to return 503 when artifacts are missing. It also tests a missing manifest. These are test definitions in the pinned source; this editorial inspection did not run them. The reviewed tests do not cover a successful model load or a loader exception.

The useful distinction is therefore specific: liveness returns a process response, `/health` exposes the loaded state, and readiness validates artifacts before attempting to load the model. None of these responses replaces evaluation of model behavior. Deployment policy should be checked against the exact handler semantics rather than inferred from an endpoint name.

This is a source-code walkthrough, not a report of a production incident or a claim that the API is currently hosted.

It avoids claiming that the model is usable solely because `/health/ready` returns a particular status; the `model_loaded` response field remains visible.

The tests are described as source definitions only. No test run is claimed.

“The useful distinction” is editorial synthesis, not an invented personal lesson or experience. The author should revise it if it does not reflect their view.