Recipe Health

This page reports the structural health of every recipe AICR can resolve — one row per leaf criteria combination (service × accelerator × OS × intent × platform), plus any non-leaf coordinate retained because it carries published dashboard evidence (a plain coordinate that gained a platform sibling keeps its row so its Evidence link is never silently dropped). It answers “across the whole matrix, what is the current structural state of each recipe?” and is the catalog-wide complement to per-recipe conformance evidence. For a family carrying an ADR-015 configuration profile (gpuStack on AKS, GKE, and OKE), the row grades the composition resolved at the declaration default (azure-managed on AKS, gke-default on GKE, oci-managed on OKE); per-profile-value rows are a follow-up.

The matrix is computed hermetically and offline: every signal is a pure read of the resolved recipe — no Helm render, no GPU, no cluster, no network. It is regenerated from the recipe catalog by make recipe-health-docs and is kept current by a weekly bot PR. make recipe-health-check is an advisory staleness check (it is not wired into make qualify or the merge gate). The full design is recorded in ADR-009.

What the columns mean

Status is the rolled-up structural verdict per recipe:

• pass — the recipe is structurally sound.
• warn — a non-fatal structural concern was surfaced.
• fail — a graded structural signal failed (e.g. the recipe does not resolve).
• unknown — a transient resolver error (a re-runnable timeout) prevented a confident verdict; the recipe is held rather than penalized. unknown is never silently read as pass.

Structural soundness is not a validation verdict. A recipe that resolves cleanly is structurally sound, not validated and performant. Runtime/validation claims come only from signed conformance evidence, which is out of scope for this matrix today (see the Evidence column below).

chart_pinned (folded into Status). One of the graded signals behind Status checks that every resolved Helm component references an explicit chart version, per ADR-006. This is layer 1 only — the chart-version pin — not image-digest pinning, and it is a render-free read of the resolved recipe (it does not pull or template the chart).

Coverage is a descriptor — it is never graded, so a deliberately minimal recipe is never penalized for declaring fewer checks. It is a compact per-phase summary of the declared validation checks, in the form R:n D:n P:n C:n — the count of named checks declared for the readiness, deployment, performance, and conformance phases respectively.

Evidence deep-links each recipe that has a live dashboard presence to its coordinate on the AICR evidence dashboard at validation.aicr.run (/#/<group>/<dashboard>/<tab>, where group is the service, dashboard is <accelerator>-<os>, and tab is <intent>[-<platform>]). A recipe without a committed presence entry stays a literal pending — the column reports the absence of a committed linkable presence, not necessarily the absence of live evidence (profiled families’ entries are deliberately withheld until profile-aware links land, so their rows read pending even when the dashboard holds per-value evidence). Today the dashboard covers only the UAT-driven coordinates, so most rows are pending until real-hardware coverage broadens; this matrix does not gate on that.

The link is constructed hermetically and deterministically from the recipe’s resolved criteria using the shared pkg/recipe.CoordinateFor mapping — the generator makes no network call, and the coordinate carries no Kubernetes version, so a link is stable across k8s-version rolls. The Evidence cell is a link and nothing more: it points at the live board and carries no pass/fail state or count. Which recipes are linked is driven by a committed presence manifest (pkg/testgrid/presence.yaml); a weekly, warning-only bot keeps it honest by reporting any link that no longer resolves against the live dashboard data (it never blocks merges or edits this doc).

Community-source posture is author-asserted provenance, not independently-verified correctness. A coordinate’s tab placement and any community-sourced results on the dashboard are declared by the signing author; corroboration counts agreement at the same AICR version but does not itself certify runtime correctness. Read the linked board accordingly.

Today every committed pointer is community class; none is first-party. The signer classes are pinned per class in recipes/evidence/allowlist.yaml — first-party is the project’s own UAT workflows, community is individual external contributors, partner has nobody onboarded. Every pointer committed under recipes/evidence/ is community class, published from a contributor fork per evidence publishing, and admitted by maintainer review. The Evidence column does not render the class, so a deep-link here does not distinguish one from the other — read the class from the allowlist. Surfacing it per row is deferred alongside ADR-009’s in-cell freshness state (#2877).

The deep-link is the current Evidence rendering. It is distinct from — and coexists with — ADR-009’s deferred, verify-gated in-cell freshness state (unattested vs aged, derived from a signed attestation’s AttestedAt): the link points at the live board, and an optional freshness token can later annotate the same cell without replacing the link. See also the coverage matrix for the complementary breadth view.

Summary

• Recipes: 58
• Pass: 58 · Warn: 0 · Fail: 0 · Unknown: 0

Recipes