UNOFFICIAL/EXPERIMENTAL. This entry belongs to the AICR catalog overview. 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, then run:
bash <(curl -fsSL https://confighub.github.io/helm-expt/site/sh/aicr-cpu-starter/try.sh)The short Try AICR page explains the output. The anonymous run receipt 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 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 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. 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
npm run aicr-cpu-starter:verify
npm run aicr-cpu-starter:self-testThe digest index 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
npm run aicr-platform-variant:verify
npm run aicr-platform-variant:self-testThe 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 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
npm run aicr-starter-variant:verifyThe 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 binds the run to the starter's committed platform digest, and the summary 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
npm run aicr-starter-delivery:verifyThe 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 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 and summary record the run; the cluster, registry, and working files were removed afterward.
One reviewed component, synced
npm run aicr-starter-sync:verifyThe 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 chains the starter's platform digest, the training entry's digest, and the variant receipt whose change it realizes; the summary 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 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.