# The CPU starter derives the shape anyone can exercise UNOFFICIAL/EXPERIMENTAL. This entry belongs to [the AICR catalog overview](./index.md). It is the third entry class: the AICR platform spine without accelerators, for anyone who wants to exercise the catalog's config mechanics without a GPU, a cloud account, or an NGC key. ## Try the public configuration first Install [ORAS](https://oras.land/docs/installation/), then run: ```bash bash <(curl -fsSL https://confighub.github.io/helm-expt/site/sh/aicr-cpu-starter/try.sh) ``` The script anonymously pulls the retained 17-Application AICR configuration, selects the seven Applications recorded for this CPU starter, verifies every file hash, and writes those seven files as a local OCI. It pulls that OCI back and compares the files before it reports success. It does not contact ConfigHub Server or Kubernetes. The short [Try AICR page](../../../site/try-aicr.html) explains the output. The [anonymous run receipt](../../../data/aicr-cpu-starter-public-proof/summary.md) records the source and output digests. This is configuration inspection, not a claim that the components or a model ran. ## What upstream does and does not offer here AICR has no accelerator-free recipe. Its kind overlays exist, but they target GPU passthrough and assume host NVIDIA drivers, and asking the pinned binary for a recipe with no accelerator at all still returns the GPU operator, the DRA driver, and the fleet health component, because the GPU stack lives in the base overlay. This entry therefore duplicates nothing upstream. It is equally true that AICR would never emit this shape, so the starter is this catalog's own derivation rather than an AICR-supported configuration, and it should be read that way. The [composition-model reference](../../reference/aicr-composition-model.md) records the check behind both statements. ## Provenance by derivation, not authorship The starter invents nothing. Every one of its seven Argo CD Applications is a byte-identical copy of a rendered Application the [training entry](./eks-h100-training-kubeflow.md) retains from NVIDIA AICR v0.14.0. What the starter adds is a selection, and the selection is recorded, not implied: two mechanical rules exclude anything whose rendered bytes reference `nvidia.com/gpu` and anything bound to the training OCI bundle by a path source, and one curated rule excludes three components whose purpose is cloud-specific or GPU-fleet operations, each with its reason written next to its name in the [derivation receipt](../../../examples/aicr/cpu-starter/derivation-receipt.yaml). The compiler refuses to compile if the curated list goes stale against the source entry. What survives is the platform spine: cert-manager, node feature discovery, the Prometheus operator CRDs, Kube Prometheus Stack, ephemeral-storage metrics, the KAI scheduler, and the Prometheus adapter, with their original sync-waves preserved. ## The derivation is pinned end to end ```bash npm run aicr-cpu-starter:verify npm run aicr-cpu-starter:self-test ``` The [digest index](../../../examples/aicr/cpu-starter/digest-index/README.md) pins the starter under one platform digest, `sha256:d4c19c203ba379690c8de8716b29712b14d69006ae928136f410f634a4a80564`, and each member payload records the training-entry payload hash it derives from plus the training entry's own platform digest. The chain from the AICR v0.14.0 release pins through the training index to the starter is checkable end to end, offline. The compiler also cross-checks every copied byte against the training index before it compiles, so the starter cannot silently drift from what the training entry pinned. The self-test proves the selection rules, the byte-identical copying, the digest sensitivity, and the refusals against fake surfaces only. ## Honest residues instead of silent edits The starter keeps the source bytes faithful. Where the retained values reference cloud resources, the index records the residue instead of editing it: today that is one reference to the `gp3` storage class inside the Kube Prometheus Stack values, which a cluster without AWS storage classes does not provide. Overriding it is exactly the variant mechanics this catalog already proves elsewhere. The local gate below checks a proposed edit before the later ConfigHub and cluster proofs use the reviewed result. ## An AI can propose the change, but the gate decides ```bash npm run aicr-platform-variant:verify npm run aicr-platform-variant:self-test ``` The accepted request asks to change the Prometheus StorageClass from `gp3` to `standard`. Before it writes a candidate, the gate checks that all seven Application identities remain, only `kube-prometheus-stack` changes, and only the declared StorageClass field changes. The output is the complete readable seven-Application configuration, not a patch that must be interpreted later. The refused fixture proposes the same storage change plus an unrequested namespace move. That YAML is valid, but the extra field is outside the selected control point. The gate writes a refusal receipt and no candidate. Its self-tests also prove that adding, removing, renaming, or changing the wrong Application is refused. The [platform variant parity summary](../../../data/aicr-platform-variant/summary.md) links to the two requests, the accepted candidate, and both receipts. This local check contacts neither ConfigHub nor Kubernetes. The live proofs below remain the evidence for retention, promotion, and cluster acceptance. ## The residue override, proven live against ConfigHub ```bash npm run aicr-starter-variant:verify ``` The starter's first live proof follows the training entry's path and closes the loop on the recorded residue. A scratch run imported the seven derived Applications as a ConfigHub base variant from a temporary OCI reference, confirmed the base Unit matched the committed starter bytes exactly, created development and staging variants, and applied the gp3 override as a reviewed change in development: ConfigHub's dry run named the one affected Application and changed nothing, then the real change moved the Prometheus storage class from `gp3` to the cluster-default `standard` and touched exactly one Application. The staging promotion was previewed first and left staging unchanged; the real promotion then carried the reviewed configuration to staging with matching canonical data. The [receipt](../../../runs/aicr-cpu-starter-variant/receipt.yaml) binds the run to the starter's committed platform digest, and the [summary](../../../data/aicr-cpu-starter-variant/summary.md) retells it in plain language. Both scratch Spaces and the temporary registry were deleted afterward, and the receipt refuses to verify unless that cleanup passed. ## Delivery to a cluster, proven at the config plane ```bash npm run aicr-starter-delivery:verify ``` The delivery proof puts the starter on a real cluster and stops exactly at the config plane. The seven Applications traveled as one OCI artifact, were pulled back byte-faithful, and were applied to a throwaway kind cluster running a pinned Argo CD. All seven were accepted with their specs and sync-waves intact, and the boundary was proven rather than asserted: the retained Applications carry upstream automated sync policies, so the application controller was held at zero replicas for the entire run, zero sync operations appeared, and every component destination namespace stayed absent. Delivery cannot begin until a human scales the controller up. The reason the controller stays at zero is now precise. It is not that the ordering is unearned: AICR declares a `deploymentOrder` per recipe, and the [ordering-parity lane](../../../data/aicr-ordering-parity/summary.md) proves the rendered sync-waves preserve it exactly. The catalog declines to run the sync in a config-plane proof, which is a different and defensible reason. The [receipt](../../../runs/aicr-cpu-starter-delivery/receipt.yaml) and [summary](../../../data/aicr-cpu-starter-delivery/summary.md) record the run; the cluster, registry, and working files were removed afterward. ## One reviewed component, synced ```bash npm run aicr-starter-sync:verify ``` The first deliberate step past the config plane takes exactly one step. The reviewed storage-class override from the variant receipt was applied to the committed Kube Prometheus Stack bytes, the result traveled as one OCI artifact with the six untouched components, and a running Argo CD on a throwaway kind cluster synced the CRD prerequisite first and then the reviewed component, in the order the sync-waves state. Both reached Synced and Healthy, and the reviewed field became real: every Prometheus volume claim bound with the cluster-default `standard` class the review selected, which is exactly what the recorded `gp3` residue prevented before the review. Scope was proven, not implied: two Applications existed on the cluster, and every other component destination namespace stayed absent. The [receipt](../../../runs/aicr-cpu-starter-sync/receipt.yaml) chains the starter's platform digest, the training entry's digest, and the variant receipt whose change it realizes; the [summary](../../../data/aicr-cpu-starter-sync/summary.md) retells it in plain language. ## It tracks one retained version, and says so The catalog retains two AICR versions now, so a derived entry has to answer whether it follows the newer one. This one does not. The starter derives from the v0.14.0 training entry and stays there. Every proof it holds, the ConfigHub import, the reviewed override, the promotion, the delivery and the sync, was produced from those bytes. Following a newer retained version would leave all of that describing an entry nobody derived. A refresh here means deriving a second starter with its own receipts, deliberately, and nothing about a new upstream release moves this one. That decision is recorded in the [derivation receipt](../../../examples/aicr/cpu-starter/derivation-receipt.yaml) rather than left as a convention, and the compiler refuses when the version it derives from disagrees with the version the naming register says this entry carries. Repointing the starter means moving both together, which is what makes the policy a rule instead of an intention. ## What is proven and what is not Proven: the selection is rule-governed, every copy is byte-identical to retained configuration, the whole entry is pinned by one digest with an end-to-end derivation chain, ConfigHub imported the starter and carried the residue override as a reviewed development-variant change with a dry-run preview, the same reviewed configuration reached staging through a previewed promotion, a real cluster's Argo CD accepted all seven Applications with zero sync operations started, and the one reviewed component synced to Healthy with its volume bound by the reviewed storage class. Not proven, and stated rather than implied: the other five components never synced, no GPU exists anywhere in this entry, and nothing here claims production, AWS, or fleet behavior. This entry has climbed every rung of the ladder; the increment that remains is config-plane delivery for the inference entry.