AICR TestGrid

The AICR TestGrid is the live validation-posture board: it shows the actual pass/fail of AICR recipes from real validation runs against real clusters, organized so you can navigate straight from a cloud service provider down to a single check. It answers “is this recipe passing right now, against which Kubernetes version, and who signed the result?”

It is the live complement to two offline, structural surfaces:

• Recipe Health — the catalog-wide structural state of every recipe, computed hermetically with no cluster.
• Recipe & CLI Coverage Matrix — which journeys and CLI verbs are exercised in-repo, and how often.

Neither of those reports live pass/fail; the TestGrid does. The three surfaces coexist and never duplicate each other — see How it relates to recipe health below. The full design contract is recorded in ADR-012.

How to read it — CSP-first navigation

The board is a five-level addressing space. You navigate it the way you reason about a deployment: start from your cloud, narrow to your hardware and OS, then your workload.

The first three levels (group, dashboard, tab) come from the recipe — they identify which cell a result belongs in. The last two (row, column) come from the validation run — they describe what is in that cell: which checks ran, in which build. A recipe never decides its own rows or columns.

This split is why the board is CSP-first even though recipe names are accelerator-first: the recipe h100-eks-ubuntu-training-kubeflow lands at the coordinate eks/h100-ubuntu/training-kubeflow. The mapping is derived from the recipe’s resolved criteria, never from string-parsing its name, so the two stay independently correct.

The coordinate

Every cell has a stable, canonical address:

<group>/<dashboard>/<tab>

For example eks/h100-ubuntu/training-kubeflow (with a platform) or eks/h100-ubuntu/training (bare intent — when a recipe declares no platform, the segment is dropped, never filled with a placeholder).

Treat the coordinate as a stable opaque identity, not a key you take apart: a dimension value can itself contain - (for example rtx-pro-6000), so the path has no reliable positional split point. It is something to link to and compare for equality, not to decompose.

The Kubernetes version facet

The Kubernetes version is deliberately not part of the coordinate. It lives in the column — one build is one K8s version. This keeps a coordinate (eks/h100-ubuntu/training) invariant as clusters upgrade, so links into the board do not churn every time a new K8s minor ships.

The trade-off is that one tab can hold columns for the same coordinate at different K8s versions. Two countermeasures keep a stale result from being read as a current one:

• a K8s-version facet / filter, so you can scope the view to a version; and
• a latest-per-signer default scope, so the default view does not mix stale and current results from the same signer.

Each column also carries the recipe’s declared K8s constraint alongside the observed version, so you can tell at a glance whether the cluster the build ran on actually satisfied what the recipe asked for.

Provenance columns — who produced the result

Trust in a column comes from its provenance metadata. Each build column carries a fixed set of keys so you can weigh a result before relying on it:

signer_identity and signer_issuer together are what let you distinguish community-submitted results from NVIDIA UAT runs, and they key the latest-per-signer default scope. evidence_digest is the verifiable anchor: every cell traces back to a signed conformance evidence artifact you can verify independently with artifact verification.

Interim evidence dashboard

The Evidence Corroboration Dashboard is the interim static GitHub Pages surface for the same evidence. It reads the same verified, source-keyed evidence tree (in the same layout) and derives recipe coordinates using the same shared mapping function (pkg/recipe.CoordinateFor, ADR-012). It is published at https://validation.aicr.run and rebuilt on every merge to main by a deterministic Go generator — no live workers, no GKE cluster.

The TestGrid (this page) is the live stack: live upstream TestGrid workers, an AICR-native read-only API, a greenfield SPA, and an always-on GKE host cluster. Both surfaces are built in parallel; neither defers the other.

The two surfaces share the same foundation:

• The same verified source-keyed evidence tree, in the same layout. (Whether the two surfaces share one GCS bucket or stand up their own is an open GP3/TG1 deconfliction tracked in ADR-012; the shared contract is the evidence tree, not a specific bucket.)
• Same recipe→coordinate mapping (pkg/recipe.CoordinateFor) as the shared criteria-only base — the anti-drift guarantee for both surfaces. (Profile-bearing recipes refine it per consumer: the Golden Path route appends the -<name>-<value> profile segment to the tab, while TestGrid keeps the unsuffixed coordinate and separates values via the digest-bound build ID — see ADR-012/ADR-015.) Both surfaces anchor every recipe to the same criteria-only <group>/<dashboard>/<tab> base; for profiled recipes the complete coordinates diverge by design (suffixed GP tab segment vs unsuffixed, digest-partitioned TG builds).
• The GP dashboard’s JSON contract (data/index.json + data/series/<recipe>.json) uses coordinate-keyed layouts that are forward-compatible with the TestGrid workers, API, and UI. It is not a throwaway interim format.

RQ1 (#1283) — the follow-on to #1224’s pending Evidence column — targets the evidence dashboard specifically: it is the link target today because TG4a/TG4b’s live API and UI have not shipped yet — not because TG work is deferred; the two surfaces are being built in parallel (see above). The Recipe Health generator (tools/health/markdown.go) deep-links the Evidence column to the dashboard’s coordinate URL today, gated on a committed dashboard presence — https://validation.aicr.run/#/<group>/<dashboard>/<tab> — built offline from resolved criteria via pkg/recipe.CoordinateFor. Recipes without a committed presence stay pending, and profiled families’ presence entries are deliberately withheld until profile-aware links land (the lowercase -<name>-<value> tab segment for a profiled recipe cannot yet be derived by the criteria-only generator). The link is stable across Kubernetes upgrades because the Kubernetes version lives in the column, not the path. Once TG4a’s own coordinate-presence endpoint ships, the same criteria-only base (Coordinate.Path()) resolves on this board too. The bases are addressed identically; only the profile refinement differs per surface — the Golden Path route appends the profile segment to the tab, while TestGrid stays at the unsuffixed base and separates profile values via the digest-bound build ID — so how a link is derived does not change when the live board comes up.

How it relates to recipe health

The TestGrid and the Recipe Health matrix are two surfaces that coexist; neither is a richer rendering of the other:

• Recipe Health owns the offline structural / freshness signal — does the recipe resolve cleanly, are its charts pinned — computed without a live cluster.
• The TestGrid owns the live validation-posture signal — derived from real runs against real clusters.

AICR keeps these axes deliberately separate so a “resolves cleanly” verdict never gets fused with a “validated and performant” one. The two surfaces share exactly one thing: the criteria-only base coordinate (pkg/recipe.CoordinateFor) by which both address the same recipe family — for profile-bearing recipes the Golden Path refines it with the -<name>-<value> tab segment (and the evidence recipe name carries the same segment), while TestGrid stays at the base, separating values by digest-bound build ID.

The Recipe Health Evidence column is the cross-link between them. When a recipe has a committed presence on the interim evidence dashboard, the column links into its coordinate — the dashboard is the link target today because TG4a/TG4b’s live board hasn’t shipped yet, not because TG work is deferred — and the link is automatically checkable so it can never point at a coordinate that does not exist. A recipe with no committed dashboard presence stays pending (profiled families’ entries are deliberately withheld until profile-aware links land). It links, it never copies either board’s content.