Catalog Promotion Review

Catalog promotion is the repeatable review that decides the support scope for a proof-grade recipe.

For the top-20 public Helm charts, catalog presence is mandatory because their upstream charts are so popular. Promotion decides what we can honestly support: local/test, production with caveats, production-ready, deprecated, or blocked.

It is both:

• a machine-verifiable harness;
• a product/readability review.

The core question is:

Is this the best, simplest, safest way for a Helm user to install and vary this
chart through ConfigHub?

Required Machine Checks

Every promoted catalog variant must pass:

• source lock and dependency lock verification;
• deterministic regular Helm render under the declared capability profile;
• cub installer package deterministic bundle verification;
• cub installer setup semantic equivalence against regular Helm output;
• rendered object inventory verification;
• digest-bound VariantRevision verification;
• render receipt verification;
• Helm-equivalence receipt verification;
• scan receipt verification;
• install-gate verification;
• self-test that rejects rendered object tampering.

Here is what the command does. cub installer is an open-source plugin for the cub CLI. cub installer setup pulls a catalog package and writes its Kubernetes files locally, leaving delivery to kubectl, Argo CD or Flux. The generated scripts stop before doing any work when the plugin or kustomize is missing.

For the current repo:

npm run verify
npm run next80:verify
npm run next80:verify:packages
npm run catalog:review
npm run catalog:review:verify

The generated review outputs are:

data/catalog-promotion-review/review.csv
data/catalog-promotion-review/summary.md

The review runner does not auto-certify catalog-supported. It checks the machine evidence and reports remaining product gaps so a human can make a support decision.

Required Product Checks

Promotion also needs a human-readable answer to each question:

Promotion States

proof-grade
catalog-candidate
catalog-supported
deprecated
blocked

proof-grade means the mechanics work. catalog-supported means we recommend the recipe and its supported variants for the declared scope.

Promotion Decision

A chart can be promoted to catalog-supported only when:

• at least one variant is useful as a real install path;
• obvious high-demand variants are either implemented or explicitly deferred;
• the README for the chart is shorter and clearer than the equivalent Helm troubleshooting path;
• all proof receipts pass;
• scan/gate status is acceptable for the intended scope;
• upgrade behavior is understood for the current chart version.

Re-Review Triggers

Run catalog promotion review again when:

• the upstream chart version changes;
• a dependency version changes;
• Kubernetes capability profile changes;
• a scan policy changes;
• a user requests a new supported variant;
• a chart introduces CRDs, hooks, webhooks, generated facts, lookup, or raw extension slots;
• ConfigHub installer behavior changes.

Current Repo Interpretation

The repo currently has 100 machine-proof recipes. All top-20 bespoke recipes are supported only for the declared local-test scope:

catalog-supported: 20
catalog-candidate: 0
proof-grade: 80

That is deliberate. They have enough evidence to recommend for local proof and demo use. They are not production-supported until a final target-scoped support decision records the scope, required live checks, and support policy.

The next 80 are full equivalence proofs for default variants. They are not automatically catalog-supported because most do not yet have user-shaped variant choices.