Parent: #739

Summary

Define and document the pinning policy for components whose Helm charts deploy many sub-images that AICR does not explicitly pin in recipes/components/<name>/values.yaml.

Motivation

Today, our values.yaml typically pins only the chart version (sometimes), leaving sub-image tags to chart defaults. This is intentional for some components (security patches flow automatically) but creates a reproducibility gap — the same recipe rendered on different days can deploy different image digests.

The largest implicit-surface components:

• gpu-operator — driver, toolkit, dcgm, dcgm-exporter, device-plugin, validator, mig-manager, vgpu-manager, sandbox-device-plugin, gfd, gdrcopy, kata, cc-manager (~14 sub-images; only driver.version is pinned)
• network-operator — nic-operator, mofed driver, sriov-network-operator, nv-ipam, secondary-network, multus, whereabouts
• kube-prometheus-stack — prometheus, alertmanager, grafana, kube-state-metrics, node-exporter, prometheus-operator
• cert-manager — controller, webhook, cainjector, startupapicheck

Proposed approach

For each component above, make an explicit decision:

Output of this issue:

• A documented per-component policy in docs/contributor/recipe-development.md
• An ADR capturing the rationale
• Where pinning is chosen, the corresponding values.yaml updates

Success criteria

• Each high-surface component has a documented, intentional policy.
• Policy is enforceable and visible in code review (e.g., new components must declare their stance).
• Decision is informed by the BOM output (separate issue).

Out of scope

• Pinning low-surface components (single-image charts) — defer until policy is set for the big ones.