How AICR composes a platform, and where it overlaps this catalog

This page explains what AICR produces and how those outputs fit the ConfigHub processing model. AICR owns source composition and its native recipe format. ConfigHub retains, compares, changes, approves, promotes, and delivers the exact configuration produced from that source.

The composition model

AICR calls its resolved source document a recipe. That is AICR's native term, not the general name for every configuration in this catalog. An AICR recipe is a declarative document, not a script. Overlays inherit from each other, mixins add capability groups, and the resolved result names its components, its ordering, and its checks.

Overlays live in recipes/overlays/ and carry kind: RecipeMetadata, apiVersion: aicr.nvidia.com/v1alpha1. Each names a base, a set of criteria, constraints, and componentRefs. v0.14.0 ships 79 of them, from base.yaml through eks.yaml and eks-training.yaml to h100-eks-ubuntu-training-kubeflow.yaml.
Mixins live in recipes/mixins/ and carry kind: RecipeMixin. v0.14.0 ships four: os-ubuntu, os-talos, platform-kubeflow, and platform-inference. The inference mixin is what adds the agentgateway Gateway API and inference-extension components.
The component registry in recipes/registry.yaml declares roughly thirty-eight components. Each entry names its Helm repository, chart, and default version, or its Kustomize source, plus a healthCheck.assertFile, a testTier, and nodeScheduling paths.
Resolution merges base, overlay, mixins, and inline overrides. The generated recipe carries criteria, constraints, componentRefs, validation, and an explicit deploymentOrder.

Running the pinned binary makes the layering visible. Asking for the training shape this catalog retains reports eight overlays resolved into thirteen components for kind and seventeen for EKS, with a deploymentOrder list that is the dependency order, not a rendering artifact.

The command surface, and what it overlaps here

AICR is a larger tool than "generate a bundle", and several of its commands address problems this catalog also addresses. Naming the overlaps is more useful than discovering them later.

AICR command	What it does	What it overlaps here
`recipe`	Resolves criteria into components and order	The catalog's recipe and dossier records
`query`	Extracts a hydrated value by dot-path selector	Control points, expressed upstream and machine-readably
`bundle`	Generates the deployment bundle	Flattening and packaging
`verify`	Verifies bundle integrity and attestation chain	The signature verification lane
`trust`	Manages the Sigstore trusted root	The committed trust root decision
`evidence`	Inspects and verifies recipe-evidence v1 bundles	Receipts, almost exactly
`validate`	Runs containerized validators against a cluster	Live proofs
`snapshot` and `diff`	Capture cluster state and detect drift	Reverse reconcile and cub-scout
`mirror`	Discovers images and charts for air-gapped use	Remote dependency closure and image lists
`skill`	Writes an agent skill file for the CLI	Generated chart skills

Two of these deserve emphasis. aicr query resolves a dot-path such as components.<name>.values.<path> or deploymentOrder against the hydrated recipe, which means AICR already publishes machine-readably what the catalog's control-point records currently declare by hand. And aicr evidence operates on evidence bundles produced by aicr validate --emit-attestation, described upstream as letting maintainers and CI verify a contribution without re-running validators against hardware they may not have. That is this project's own receipts thesis, arrived at independently by the upstream project.

What v0.19.0 adds to the field-ownership model

AICR v0.19.0 introduces named gpuStack profiles for its AKS and GKE source families. A selected profile owns a related group of fields. Bundle generation refuses a conflicting value and refuses to expose a profile-owned path as an install-time parameter.

That maps directly to ConfigHub's protected-field decision:

Keep the selected AICR profile in the source-and-intent record.
Regenerate the base when a change belongs to that profile.
Use a derived ConfigHub variant only for a field the selected source leaves open to later change.
Review an overlap before promotion when a refreshed source and a retained variant both touch the same field.

The retained EKS H100 training recipe is unprofiled. Selecting the AKS gpuStack profile for it is refused. We therefore record GPU-driver ownership as unresolved target-specific work for this EKS entry rather than applying the AKS rule to a different source family. The exact commands and results are in the field-policy assessment.

This gives each record one job:

the AICR recipe records the selected platform source;
the generated Helm chart records the source package Argo CD can process;
the exact Application revision records what ConfigHub can retain now;
the route intent records lifecycle work around apply; and
receipts record which generation, check, promotion, delivery, or runtime step actually ran.

What the study settled about our entries

The inference entry could have been AICR-native. At v0.14.0, platform: nim is a first-class criteria value with its own overlay, and k8s-nim-operator is a registered component. Generating that recipe produces seventeen components including the NIM operator at 3.1.0 and the agentgateway inference gateway. The catalog instead retains the KServe subtree of NVIDIA/nim-deploy, which is a legitimate NVIDIA reference implementation under Apache-2.0, but it is a different repository and a different deployment approach. The choice was made without knowing the native path existed, and the earlier description of nim-deploy as the strongest upstream candidate for an inference shape is therefore wrong and is corrected on the entry pages.

The CPU starter is not a duplicate of an upstream path, and it is also a shape AICR would never emit. AICR's kind overlays exist, but they are for GPU passthrough and assume host NVIDIA drivers. Asking for a recipe with no accelerator at all still returns gpu-operator, nvidia-dra-driver-gpu, and nvsentinel, because the GPU stack lives in base.yaml. There is no accelerator-free recipe. The starter therefore fills a real gap rather than duplicating one, and the honest framing is that it is this catalog's own derivation rather than an AICR-supported configuration. The entry pages now say so.

The deployment order is upstream data. Recipes carry an explicit deploymentOrder. The rendered Applications encode that order as sync-waves, and the delivery proof holds the application controller at zero because ordering was treated as unearned. The ordering is not unearned; it is declared upstream, and the proof can eventually cite it rather than avoid it.

What this changes about the catalog's posture

The catalog's value proposition for AICR was retention, digest pinning, and receipts. Retention and digest pinning remain unambiguously ours. Receipts overlap upstream evidence bundles, and the honest position is that the catalog governs configuration across producers while AICR validates its own recipes against hardware. Those are complementary, but the difference should be stated rather than assumed, and the wording on the public pages should not imply the catalog invented provenance for a project that ships its own attestation chain.

What was not studied

The aicrd daemon shipped in the release assets, the containerized validators, the evidence bundle format in detail, the snapshot schema, and the validation dashboard were all left for later. Nothing here claims knowledge of them.