Measured 2026-09-26T08:15:42Z from DooPlex, read-only: a7head.py sends one registry HEAD per ref@digest (anonymous token; a HEAD is not a pull and does not count against Docker Hub's pull limit).

The fact. A recovery unit records image_pins and — since v0.275.0 — each data file's running ref@digest (data.files[*].images); the manifest's own note says "image NOT stored — re-pulled on restore". So a restore of a version works only while the registry still serves that version. If a maker deletes an old tag or digest, a unit of that version cannot start, and v0.275.0's rule (a restore brings the data back at its own version) makes that dependency sharper: the restore asks for exactly the old version.

Today. The catalog records digests only in its ladder entries (update_ladder[].digest): 42 distinct ref@digest pairs, all 42 answer 200 (a7-result.txt). Negative control: the same instrument answers 404 for an invented digest on Docker Hub and on ghcr.io (a7-negative-control.txt), so a 200 is not the instrument's only answer. The 66 compose image lines carry no digest in the catalog (the box adds one when it pins from a ladder entry); a tag can be re-pointed or deleted without any digest to check against, so this measures what is checkable, not the whole exposure.

Not measured: the digests actually recorded on boxes (installed_images), which include versions older than any ladder entry; how often makers delete old versions (no history kept); the from side of ladder entries (no digest recorded there).

Options, not decided (filed as a row): (a) keep as is — a restore of a deleted version fails with the pull error, and the household's route is the next copy or a newer version; (b) mirror every image a box has INSTALLED into the DooPlex registry (gitea.dooplex.hu) and let a restore fall back to the mirror — storage and bandwidth on DooPlex, and a new moving part on the recovery path; (c) mirror only the versions the ladder names (bounded by the catalog, not by the fleet) — does not cover a box on a pre-ladder version; (d) store the image in the unit (docker save) — hundreds of MB per app per copy, on every tier including off-site.