The direct answer
Do not infer that an unchanged build instruction ran again because its secret value changed. Record the actual cache disposition and the result your job requires. Reuse can be valid for an explicitly admitted snapshot; a fresh-execution requirement needs separate supported evidence and current authorization.
Ask whether reuse is permitted before expecting a rerun
A team rotates temporary dependency-access input for an AI preprocessing worker and rebuilds an unchanged recipe. Its review note says the worker must now contain freshly retrieved dependencies because the credential changed. That inference needs evidence about the selected instruction and output, not simply the new secret reference.
This worksheet selects one already admitted fixed instruction, controlled inputs and an independently reviewed cached result. The build-input guide still owns temporary supply and retained products; the context guide owns eligible files. Here the new question is whether a prior result may be reused and whether a task instead requires supported fresh-execution evidence.
Keep the documented cache decision narrow
Docker’s build-cache invalidation guide describes checking instructions against cached layers. RUN caching is not automatically invalidated between builds; an unchanged instruction does not establish refreshed external package state. Secret contents are excluded from the build cache, so changing a secret value does not invalidate it. Secret identifiers and mount paths do participate in the cache checksum.
The maintained page supplies no displayed numeric builder revision or installed-environment evidence. Complete actual builder, frontend, cache availability and input associations remain unexamined. The documented exclusion does not establish that our proposed build will hit a cache: another dependency or missing entry could change its disposition.
Likewise, a cache miss is not a certificate that a desired dependency snapshot or approved output was obtained. Keep selection, execution and result admission as separate fields. This article supplies no invalidation command, cache-key implementation, secret value or cache-removal procedure.
Declare the result requirement independently of credential handling
Invent fixed build plan B-A, admitted dependency snapshot D-A and previously reviewed output O-A. K-A and K-B are symbolic secret references, not values, hashes or credentials. They label value revisions while the selected secret identifier and mount path stay fixed. Both stand for an independently authorized temporary input channel; this article does not establish that channel or authorize its consumer.
Task J-A explicitly requires D-A and permits reuse of admitted O-A. If complete supported associations and current rights hold, a previously produced result can satisfy that particular plan. Requiring a new attempt merely because one is available would be a different policy, not an automatic security improvement.
Task J-B instead requires independently supported fresh instruction evidence under its current approved inputs. Merely replacing K-A with K-B’s value cannot fill that evidence field. Keep J-B held until its actual freshness requirement is established through an authorized supported process. Do not silently downgrade it to J-A’s reuse policy.
These are original application rules. They distinguish the requested evidence rather than assume every build needs the newest remote packages or that every cached result is acceptable. Required dependency revisions, consumer behavior and current data rights remain separate admission decisions.
Preserve a small cache and result receipt
| Field | Required evidence |
|---|---|
| Plan | Exact approved instruction, complete controlled input baseline and supported builder profile. |
| Task requirement | Explicit permission for admitted-snapshot reuse, or separately defined fresh-execution requirement. |
| Cache disposition | Supported observed reuse, execution or unknown status for this instruction. |
| Output association | Exact O-A/D-A provenance and completeness, independently admitted under current policy. |
| Release | Current recipient/job rights and stable association through handoff. |
The useful positive is conditional eligibility of J-A’s exact reuse plan after every required field holds. It does not report that a build occurred, that a credential was checked again or that a worker ran O-A. Do not replace the receipt with one green “build succeeded” flag.
Actual complete inputs, trusted cache provenance, builder support, instruction outcome, output verification and current authority are unimplemented or unknown here. Missing required evidence blocks a real positive. An old approval of a cache entry cannot override a current prohibition on using its result.
Review eight inert cache decisions
All eight cards are PROPOSED_UNRUN. They compare symbolic records; no cache entry, secret or image was constructed.
| Card | Condition | Proposed disposition |
|---|---|---|
| 1. Permitted snapshot reuse | J-A permits exact O-A/D-A, and every receipt field holds. | Conditionally admit only that reuse plan. |
| 2. Rotated value, required fresh execution | K-B replaces K-A’s value, but J-B lacks required execution evidence. | Keep J-B held; rotation does not supply that evidence. |
| 3. Remote state changed | A package source changed while the reviewed instruction stayed the same. | No refreshed-dependency claim from the recipe alone. |
| 4. Secret properties changed | Identifier or mount association differs from the baseline. | Review the changed input plan and cache association. |
| 5. Reuse reported, output unknown | A hit label exists without admitted O-A provenance. | Withhold output admission. |
| 6. Execution reported, snapshot unknown | An instruction ran, but desired dependency/output evidence is incomplete. | No correctness or release claim from execution alone. |
| 7. Reuse policy revoked | O-A still matches earlier records, but current job rights no longer permit it. | Reject reuse under the changed policy. |
| 8. Actual cache disposition unknown | Builder support, input association or result capture is missing. | Preserve unknown; no automatic purge, alternate builder or invented success. |
Separate any new execution plan from this review
If a legitimate task requires new execution, prepare a separately reviewed supported plan that establishes that requirement and its resulting output. This worksheet gives no cache-busting argument, global purge, forced rebuild or recovery command. Availability pressure does not authorize destructive cleanup or a weaker input channel.
Do not use a secret itself as a public cache label or copy it into a review record. Keep minimized plan, snapshot, disposition and rights references. Existing consumer, diagnostic, retained-copy and distribution reviews remain necessary; this new decision supplies no clean-image or erasure guarantee.
No Docker build, cache lookup, image, secret, dependency request, registry, candidate API, model or runtime experiment occurred. Only documentation and editorial work took place. Boundary is prelaunch with planned request-path checks, not a shipped cache verifier or build coordinator. Its synthetic policy evidence concerns different behavior.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.