New to cub? Install the cub CLI first. Public catalog packages pull and render anonymously, and you sign in only once a command saves or changes ConfigHub data.
What is a configuration?
Read one exact set of objects
A configuration is one exact set of Kubernetes objects, the record of how they were produced, and the lifecycle work around them. You read, diff, and check it before anything runs.
Ask four questions
Four questions place any configuration: what do I have, what will it produce, can this destination accept it, and did it work. The first two need no cluster and no account.
Bring any format
Start from what you have: Helm · OCI · Flux, Argo CD, or kubectl · Kubara · AICR · plain YAML · Timoni and the rest. Each becomes the same reviewed base.
1. Follow one configuration from source to running
The model is one line. Here it is for one real entry, NVIDIA's GPU Operator.
Flatten it. Put it in an OCI bundle, with a plan if it needs one. Load it into ConfigHub.
| Step | What happens | For the GPU Operator |
|---|---|---|
| 1. Flatten | A source is turned into plain Kubernetes objects. | NVIDIA's Helm chart, version 26.3.3, with its default values. Helm gives 24 objects. |
| 2. Bundle | The objects go into one OCI bundle, with a plan if they need one. | 24 objects and three plan documents, in one OCI artifact. |
| 3. Load | The bundle is loaded into ConfigHub. It becomes a base, and each environment gets a variant. | A dev variant and a QA variant. An upgrade from 26.3.2 changed 7 of the 24 objects. It was promoted to dev and then to QA. |
Helm ran once, when the Catalog built the bundle. Nothing runs it again when you install.
The first two steps need no account. ConfigHub starts at step 3. The model page has the three steps in full.
Deploy the GPU Operator from the Catalog does this in four steps.
The GPU Operator Guide has the commands for each row and the output they printed.
You can go round again at any point. A new chart version makes a new OCI bundle. A variant can add a need of its own. A cluster can change how a plan is carried out.
The earlier five stages, in the Catalog's own terms
This page used to name five stages, Source, Base, Variant, Deliver and Run. Flatten covers source and base. Loading into ConfigHub covers variant.
Every source reaches the same shape through the same five stages, even when a stage does nothing. Helm renders, Timoni builds, AICR and Kubara generate or compose, and literal YAML or configuration OCI is already there.
- Source. The input you already use. It can be a Helm chart, Timoni module, AICR or Kubara recipe, installer package, OCI, or Kubernetes YAML.
- Base. Materialize the exact Kubernetes objects, and capture the revision and its digest. Note the lifecycle requirements, decide the flattening lane, and retain a reviewed base.
- Variant. Derive or edit a variant, then recheck the source, flattening, lifecycle, and ownership facts it affects.
- Deliver. Resolve the lifecycle routes for that variant and destination, then compare, test, approve, promote, and publish the release by digest.
- Run. Reconcile the objects, do the lifecycle work, observe, and record receipts.
This is not a one-way pipeline. A source upgrade rematerializes the base, a variant can add a prerequisite, and a destination can pick a different route without changing the objects.
What the model keeps apart
- Produce or read the exact objects. Helm renders, Timoni builds, AICR and Kubara generate; literal YAML and configuration OCI are read as they are.
- Keep the identities separate. The base revision, exact object set, source OCI, ConfigHub Unit, and release OCI each have their own digest. A receipt names both sides of a handoff rather than treating unlike hashes as one.
- Plan the work around ordinary apply. CRDs, hooks, setup Jobs, and prerequisites become recorded plan steps, resolved once the variant and destination are known.
- Change, promote, and deliver a reviewed variant. A derived variant edits a base after render; ConfigHub reviews, approves, promotes, and releases it, keeping non-overlapping changes on upgrade.
What each step means
- Source package or configuration is the input you already use. It can be a Helm chart, a typed Timoni module, an AICR recipe, an installer package, Kubara or Sveltos configuration, OCI, or Kubernetes YAML.
- Processing intent records the source identity and the choices needed to produce or select exact objects.
- Materialize means produce or read those exact objects. Helm renders, Timoni builds, AICR and Kubara generate or compose. Literal YAML and literal configuration OCI are already materialized, so this step is a recorded no-op.
- Exact configuration revision is the accepted object set, inventory, and digest for one revision.
- Flatten means retain those exact objects so delivery does not rerun the source processor. The verdict is
safe-to-flatten,flatten-with-routes,unsafe-to-flatten, orborn-flattened. - Lifecycle requirement records work or target state needed around ordinary apply, such as CRDs, hooks, setup Jobs, certificates, cloud resources, controllers, or prerequisite Secrets.
- Plan step records portable handling the source or base proposes, and the records call it a route intent. A resolved lifecycle step binds it to an exact variant, destination, runtime, order, actor, and checks. An explicit
no route requireddecision is different from a missing record. - Protected local field records downstream field ownership, so a source refresh does not silently overwrite an environment's own value.
Four questions, asked in order
The same four questions apply to Helm, AICR, Timoni, Kubara, installer packages, OCI, YAML, and retained ConfigHub revisions.
| Question | What answers it | Needs a Catalog match? | Needs destination access? | Needs it deployed? |
|---|---|---|---|---|
| What do I have? | Inspect the source, exact files, OCI, or a snapshot of an existing system. | No | Usually no; a live snapshot needs read access to what it measures. | No |
| What will it produce? | Run the source-native materialization step, or read the objects when the source is already literal configuration. | No | No | No |
| Can this destination accept it? | Check the exact candidate against the chosen destination's APIs, CRDs, Secrets, policies, controllers, credentials, hardware, and lifecycle requirements. | No | Yes | No |
| Did it work? | Check the delivered revision, controller result, resource health, runtime behavior, drift, and rollback result the claim requires. | No | Yes | Yes |
A Catalog entry can shorten any investigation, but it is never a prerequisite for inspecting or processing your own configuration. If the required destination or deployment does not exist, the check is blocked or not run. That is not a failed configuration, a failed workload, or a failed conformance result.
The command at each stage
Each stage is a real command. The first are free and need no account; upload and release need a ConfigHub organization.
| Stage | The command that does it |
|---|---|
| Check what a source installs, and hand it on as a verified image | cub config check <name> --out oci://… |
| Check a whole composition before it renders | cub stack check |
| Retain a reviewed base in ConfigHub | cub variant upload |
| Derive a variant for an environment or target | cub variant create |
| Publish the reviewed release by digest | cub release publish |
A configuration that is unsafe to flatten does not fall out of this model. Its source stays authoritative and its processor runs late, at install time. But the result rejoins at the base step. The render-late objects are retained, derived, promoted, and released like any other base, and only where the objects are produced differs.
Where ConfigHub fits
ConfigHub is where a reviewed base becomes shared, governed configuration. cub variant upload creates the base variant: a Space labelled Component=<name>, Variant=base that holds the configuration as one Unit per resource, with no target. Secrets are the exception, because the upload skips them. A component is the set of Spaces that share a Component label, so the base is the component's first Space. From there ConfigHub's own verbs release, promote, gate, approve, and roll back.
So one uploaded configuration is one component's base variant held in one Space: the same thing named from four sides. Stacks and fleets defines what comes next. Several components compose into a stack, which becomes a platform once it runs under governance with your apps on it. The handoff runs base, then stack, then platform, with an app placed on either.
The full record is in the ConfigHub data model, and the catalog doctrine gives the same lifecycle for every source in more detail.
2. See what each format becomes
Whatever you start from, you end with Kubernetes objects. What differs is the tool that produces them.
Helm renders a chart. Timoni builds a module. AICR generates Argo CD Applications that point at charts. Plain YAML is already objects.
AICR needs one caution. A recipe's verdict covers the Applications it generates. The charts those Applications point at are judged separately, and they can still need Helm at install time.
The same point in the Catalog's own terms
Every source ends as the same exact objects, but each takes a different path there and is checked for different things. Flattening is evaluated at each processing boundary, so an AICR Application set can be flattened while the Helm charts it references stay render-late.
| Source | Materialize | Flattening result | What is checked | Example |
|---|---|---|---|---|
| Helm chart | Run Helm with the recorded values and render context. | safe-to-flatten, flatten-with-routes, or unsafe-to-flatten | Render matches Helm's own output; hooks, CRDs, and generated state are inventoried. | Redis |
| Timoni module or bundle | Build the pinned OCI module with its typed values. | Flatten, flatten with a plan, or run the workflow late. | Typed schema and selected values; ordered apply sets, waits, and target lookups. | Timoni Redis |
| AICR | Run its declared composition step, including nested Helm work it declares. | Flatten the generated layer, flatten with a plan, or process part late. | Component order, required controllers, GPU or cloud facts, and nested sources. | Inference platforms |
| Kubara or another generator | Run its declared generation step, including nested sources it declares. | Flatten the generated layer, keep a plan beside it, or process the source late. | Platform prerequisites, component ownership, and controller work. | Build a platform |
| Installer or source OCI | Pull by digest, then invoke the processor it declares. | Decide from the produced objects; a source OCI is not automatically deployable. | Package role, processor, selections, and receipts. | Try Redis |
| Literal configuration OCI | Pull by digest and read the objects it already contains. | born-flattened; record whether a plan or protected inputs travel beside it. | Object inventory, provenance, and any prior transformation. | Flux, Argo CD, or kubectl |
| Sveltos | Read the literal fleet configuration; materialize each referenced source separately. | born-flattened for the fleet objects; the referenced Helm stays a later boundary. | The literal ClusterProfile objects, plus each nested source on its own. | Stacks and fleets |
| Plain Kubernetes YAML | Read, parse, and canonicalize the files. | born-flattened, or flatten-with-routes when an operator or a Secret comes first; record requirements, ownership, and later packaging. | File checksums, object inventory, and checks. | Check my config |
| ConfigHub Units or release OCI | Read the retained objects and revision history. | Already retained as data. | Space, revisions, approvals, release digest, and receipts. | What ConfigHub adds |
Every format above is a real catalog entry you can browse. Open the Catalog and use its Format filter to list one, for example all AICR platforms or the Timoni module.
The ways a configuration enters
The Catalog has records for seven concrete entry forms, and each keeps the team's existing source rather than replacing it.
- Helm: keep the chart and values, record the render context, and capture one exact render variant.
- AICR: keep the native recipe and selected options, then record each generated boundary and its controller requirements.
- cub installer source OCI: pull a public multi-preset package by digest, pick one preset, and record its exact objects.
- Kubara or another generator: keep its native source and inputs, then record the generated platform configuration and nested sources.
- Sveltos: retain the literal fleet configuration while keeping the referenced Helm source as a later boundary.
- Literal configuration OCI: pull exact objects by digest and import them without rerendering.
- Plain Kubernetes YAML: read and retain the supplied objects without a render step.
A ConfigHub revision or release OCI can also re-enter the model as an exact retained revision. An OCI artifact can carry source material, literal configuration, or a ConfigHub release. Its role and consumer are recorded, not inferred from the word OCI.
In terms you already use
If you think in plain Helm: the recipe is your pinned chart and values. A base variant is the output of helm template for one values choice, kept as reviewable files. A derived variant gives one environment its own recorded version and keeps its changes through upgrades.
If you think in Kustomize: a base variant plays the role of a base, and a derived variant plays the role of an overlay. The base is already rendered rather than patched at build time. The overlay is a ConfigHub Space with revisions, gates, and an upstream link.
If you start with literal YAML or configuration OCI: the objects are already flat. Record their source and digest, attach any required steps, and retain them as a base. Do not pretend they passed through Helm.
If you start with AICR: use snapshot and diff first when the question is about existing GPU-node state. That path needs no recipe and tells you what differs, not what the node should contain. Select the provider-curated leaf variant before judging the difference, then retain the exact objects as a base.
If you start with Timoni: pin the module or bundle OCI, keep its typed schema and selected values, and build the exact objects. Record any ordered apply sets, waits, or target lookups that must still run. The built objects are an exact configuration revision, not a Helm render variant.
3. See whether a configuration can be flattened
Why some entries come with a plan
Take Helm. It does more than write YAML. It applies CRDs before the objects that need them. It also runs hook Jobs at set moments, such as before an upgrade.
When the Catalog keeps a chart as plain objects, Helm is no longer there to do that work. So the Catalog writes each of those jobs down. It ships that list in the same bundle as the objects. The list is the entry's plan.
The Catalog's records call the steps in a plan routes. That is where the verdict name flatten-with-routes comes from.
What the GPU Operator's plan says
The published bundle for NVIDIA's GPU Operator 26.3.3 holds 24 Kubernetes objects and three documents. The three documents are its plan.
| Document | What it tells you to do |
|---|---|
| Target requirements | Create the namespace gpu-operator first. The bundle does not contain it. |
| CRD ordering | Apply the five CRDs first. Wait until each one is established. Then apply the other 19 objects. |
| Lifecycle actions | Before an upgrade, run the chart's Job that moves the CRDs to the new version. After a delete, run the Job that removes the node-feature-discovery labels from the nodes. |
You upload the bundle to ConfigHub as it is. The three documents arrive beside the 24 objects, one Unit each. The GPU Operator Guide does this and promotes the result through dev and QA.
ConfigHub stores the plan. It does not carry it out. You do, or your pipeline does.
Under Argo CD the plan says to order the CRDs with sync waves. The Catalog has not run it that way. In its one recorded delivery of this chart, Argo CD applied the CRDs before the other objects in a single sync.
The 24 objects are final. The plan never renders them again.
Test a plan yourself
You do not have to take a plan on trust. Every packaged base has a script that carries out the install part of its plan. It uses kubectl on a cluster you choose and needs no account.
This is the script for the GPU Operator 26.7.1 default base. Read it first, and point kubectl at a throwaway cluster.
curl -s -o try.sh https://confighub.github.io/helm-expt/site/sh/nvidia-gpu-operator-v26-7-1/default/try.sh
bash ./try.shThe script creates the namespace, applies the eight CRDs and waits for each one, then applies the rest. Its output names each step as it runs.
The Catalog ran it on 10 October 2026 on a local cluster with no GPUs. It finished in 8 seconds. The operator and the node-feature-discovery pods came up, and the ClusterPolicy reported ready. The log of that run has every line.
On a cluster that already holds older CRDs, the script stops and says how to let it apply the package's own.
The script covers install. It does not run the Jobs the plan names for an upgrade or a delete, and its last line names them. The Catalog carried out those steps by hand for the GPU Operator on 11 October 2026, from 26.3.3 to 26.7.1. The pre-upgrade Job moved the CRDs, and the post-delete Job removed all 55 node-feature-discovery labels. The log of that run has every line.
A second script, try-objects.sh, tests the retained objects themselves. It fetches the retained file, checks its SHA-256 and applies it with kubectl, so it needs no cub. The Catalog ran seven of these scripts on local clusters on 11 October 2026, and the log of that walk shows each run.
Each entry page links its own script under "Advanced: apply it or upload it".
What a plan can hold
A plan can hold five kinds of step. Each kind is due at a different time.
| Kind of step | Example | When it is due |
|---|---|---|
| Something the cluster must already have | GPU Operator. The namespace gpu-operator must exist. | Before you deliver |
| The order to apply things in | GPU Operator. Apply the CRDs first. | When you deliver |
| A job to run at a set moment | GPU Operator. Run the CRD Job before an upgrade. | On upgrade or delete |
| A choice that is still open | An AICR recipe. Replace the placeholder node selector with your own cluster's label. | Before you deliver, by making a variant |
| Rendering that is still to come | An AICR recipe. Argo CD renders the charts that its Applications point at. | When you deliver, on the cluster |
The GPU Operator's plan has the first three kinds, so nothing is rendered again. An AICR recipe's plan also has the last two. Every entry page lists the open choices under "What is fixed, and what you supply".
What each verdict means
Every Catalog entry has one of four verdicts.
safe-to-flatten. The plain objects are everything. There is no plan.flatten-with-routes. The plain objects come with a plan, as the GPU Operator's do.unsafe-to-flatten. The chart depends on something plain objects cannot carry safely, so the Catalog publishes no bundle for it. A chart that reads a value from the cluster is one.born-flattened. The source was plain YAML to begin with.
The Catalog ships a chart two ways
Every chart version in the Catalog is published as an installer package. The package holds the objects of every preset, already rendered. cub installer reads it and runs no Helm.
Where the verdict allows, the Catalog can also publish one preset as a bundle. A bundle holds that preset's objects and its plan. Each entry page says whether its bundle is published.
An unsafe-to-flatten chart has the installer package only.
Why both ways are kept
Flattening means keeping the exact Kubernetes objects as the configuration that later systems review and deliver. The source stays recorded, but its processor does not run again in the delivery path. Flat objects can be read, compared, scanned, changed one field at a time, stored as OCI, or held as ConfigHub Units. It is not safe to assume every chart can be flattened without more work.
The next paragraph is earlier wording, and one claim in it is wrong. The installer packages in the Catalog hold rendered objects, and none carries an un-rendered chart.
Two delivery models coexist. The catalog packages charts render-late: the installer package carries the un-rendered chart, and the toolchain renders at install time. The eks-inference example renders early: CI flattens charts to literal YAML, publishes OCI bundles, and delivery never runs Helm. Neither wins as a doctrine. The catalog machinery certifies, the flattened-bundle shape delivers wherever certification allows, and the flattening-safety verdict arbitrates. Render-late stays the certified route for charts the verdict rejects, chosen by receipt rather than by taste.
What has to travel with each verdict
| Verdict | Use it when | What must travel with the YAML |
|---|---|---|
born-flattened | Literal YAML or configuration OCI already contains the exact objects. | Source identity, checksums or digest, inventory, checks, ownership, and any lifecycle requirements. |
safe-to-flatten | The exact source configuration has no required processor behavior outside the materialized objects. | Pinned source inputs, object inventory, digest, checks, and evidence. |
flatten-with-routes | The objects are usable once named CRDs, hooks, certificates, Secrets, setup Jobs, or ordering steps are handled deliberately. | The same records, plus a plan step for each requirement, resolved after the variant and destination are known. |
unsafe-to-flatten | The source depends on live lookup, generated state, or destructive lifecycle behavior that has no adequate plan for this use. | The source and inputs stay authoritative. Process the source late (render late for Helm) and record what must still be checked at deployment time. |
A verdict is decided per base, not per chart. The same chart with auth.existingSecret set is a different question from the same chart without it. The recorded scope says which values move the answer.
How many entries have each verdict
Of 528 entries, 520 have a verdict. 314 come with a plan. 107 need Helm at install time, so they have an installer package and no bundle.
137 of those 314 verdicts cover only the Argo CD Application wrapper of an AICR recipe. They say nothing about the charts inside it.
safe-to-flatten: 96 entries.flatten-with-routes: 314 entries.unsafe-to-flatten: 107 entries.born-flattened: 3 entries.- not assessed yet: 8 entries.
Two plain examples of what a flattened render would lose:
- A chart that reads a cluster value with Helm
lookuphas no answer until install time. Flattened, it bakes in whatever the lookup returned when the render ran, or nothing, so the objects are stale or empty. - A chart that generates a password in a hook produces a fresh secret each install. Flattened, that generation step is gone, so the rendered Secret carries one fixed value instead.
A base's verdict is one chart at a time. A stack's flattened release is a second judgement on top. It holds only when every part's verdict permits flattening, so one unsafe-to-flatten part keeps that part render-late even inside an otherwise flattened stack.
What happens after the verdict
An entry whose verdict allows plain objects follows the five stages in section 1. Its objects are rendered once and kept. Where a bundle is published, you upload it to ConfigHub as it is.
An unsafe-to-flatten entry has its installer package and no bundle.
A published bundle shows that the objects were rendered and packaged as recorded. It does not show that they run.
The build steps, in the Catalog's own terms
A source whose verdict permits flattening flows through one shape, whether it is a Helm chart, a Kubara-generated tree, an AICR recipe, or raw YAML. The verdicts that permit it are safe-to-flatten, flatten-with-routes, and born-flattened.
- Render or flatten once, with declared inputs, at build time and never in the delivery path.
- Package as a certified bundle: one OCI artifact per component, a digest-bound index pinning the composition, and a receipt.
- Ingest as Units, one for each resource, with the bundle digest recorded, into a base Space no target deploys.
- Vary per target, then publish governed releases against an immutable digest.
- Any reconciler syncs that digest: Argo per cluster, Sveltos across a labeled fleet, plain kubectl for the minimal path.
- Receipts close the loop where convergence is recorded.
An unsafe-to-flatten source is rendered too, and its objects are in its installer package. No bundle is published for it.
The receipt certifies rendering and packaging, not runtime health, and convergence receipts stay separate. A decided lane does not mean a bundle exists or ever will. Publication is a separate step, gated on the lane permitting it, and an unsafe-to-flatten entry must never carry a certified-bundle receipt.
The rules are in when to flatten configuration, deciding a flattening lane, and the certified bundle spec. The certified bundles record lists the flattened ones so far.
Choose a tool and start picks the tool for what you want to do now. It also covers a chart the Catalog does not have.
4. What each catalog entry contains
Open any entry and you find the same five things. Here they are for NVIDIA's GPU Operator 26.3.3.
| Part | What it is | For the GPU Operator |
|---|---|---|
| The package | The chart itself, pinned and signed. Helm runs when you install it. | NVIDIA's chart at 26.3.3, as a signed installer package. |
| The bases | The chart rendered for one set of values. An entry can have several. | A default base, one for each driver version, and one for nodes that already have the driver. |
| The bundle | One base's plain objects, published as an OCI image. | The default base's 24 objects. |
| The plan | The written list of work Helm used to do. | CRD ordering, and two lifecycle actions. |
| The receipt | The record of what was checked, with digests. | The render was compared with Helm's own output. Nothing was run on a GPU. |
Where each part is explained
Every version has a local detail page for its package, configurations, and receipt. The bold version in each row is the one summarized by that row's readiness and evidence. Retained-only version pages prove publication and inspect identity; they do not inherit another version's readiness or live proof.
Every entry carries the same parts, and each one is explained on Config.
- The package. The pinned source and its inputs. See the recipe step.
- The bases. One reviewed starting configuration per tested choice. See what a base variant is.
- The bundle, where the lane permits it. The exact objects kept as a certified OCI image. See when a configuration can be flattened and see the bundle's OCI shape.
- The plan. The CRDs, hooks, and setup work, in order. See what a chart hides.
- The receipt. What was checked, and the digests it names. Check why you can trust it.
Helm charts
- If My Chart Has Hooks, What Happens?
- Hook Lifecycle Strategy
- Helm Chart Presets And Values
- Helm Render Intents
- Extension Slots
- Helm Pain Points
- Coming from Helm? How your habits map to cub
- Seven-Stage Helm Lifecycle
- How The Harness Works
- Target Prerequisites
- Prometheus High-Fanout Example
- NGINX Configuration Files
How the catalog handles required setup
The chart page names any CRDs, hooks, setup jobs, generated Secrets, or other target resource a chart needs, before you choose a configuration. See what your chart's hooks, CRDs, and setup work become.
5. Read each result correctly
A Catalog page answers four questions about an entry. The first two need only the page. The last two need a real cluster.
| Question | What answers it | For the GPU Operator 26.3.3 |
|---|---|---|
| What do I have? | The source and its version. | NVIDIA's Helm chart, 26.3.3. |
| What will it produce? | The exact objects. | 24 objects, linked from the entry page. |
| Can my cluster accept it? | A check against one named cluster. | Not checked. The entry lists what a cluster must have first. |
| Did it work? | A recorded run. | One run, on a cluster with no GPUs. |
When a check could not run, the page says blocked or not run. That is a different result from a check that failed.
The four questions in the Catalog's own terms
The Catalog can give you a source and exact objects without a cluster. Destination and live answers appear only when the required target or deployment evidence exists.
| Question | What the Catalog shows | What it needs |
|---|---|---|
| What do I have? | The exact source, version, choices, package, files, or snapshot. | No Catalog match, destination, or deployment is required. |
| What will it produce? | The exact materialized Kubernetes objects and their identity. | The source-native processor, unless the source is already literal configuration. |
| Can this destination accept it? | A check of APIs, CRDs, Secrets, policies, controllers, hardware, and lifecycle work for one named destination. | Destination access; the candidate does not need to be deployed. |
| Did it work? | The recorded controller, resource, workload, runtime, drift, and rollback results that were actually checked. | The exact selected revision must have been deployed. |
A missing prerequisite is reported as blocked or not-run. It is a different result from a configuration that failed, and we keep the two labelled apart.
Each row also carries a flattening verdict, in the "Flattens as plain YAML?" column. See what each verdict means and how many bases fall in each lane. A row's hook or CRD signal links to what your chart hides.
6. Why the catalog offers several configurations
A Helm chart can expose hundreds of values. Nobody can test every combination. So the Catalog renders each chart for a few common choices and keeps each result.
Each result is a base. Its page records the values that were used, the rendered YAML, the setup it needs, and what was checked.
The choices differ by chart. The GPU Operator has a default base, one for each driver version, and one for nodes that already have the driver. Redis has one that reuses a Secret you supply.
How the values for each configuration are chosen
The default base is the chart's own defaults, with the image pinned by digest.
Sometimes a chart's default is unsafe. Redis default writes a password into a rendered Secret. The Catalog keeps that base, so you can see the problem. It adds reuse-existing-secret beside it, which names a Secret you supply and puts no password in the render.
Every value in a base is recorded with where it came from. It is a chart default, a Catalog rule such as pinning the image, or a generated value such as a password.
Each base's render is compared with Helm's own output. A new base is added when a real choice needs one, and it must pass that comparison first.
The Catalog has checked these named bases. It has not checked your own values file. Render and check that yourself with Is my configuration right?
See where Helm values, later ConfigHub changes, install work, and live state belong.
Every maintained entry uses the same configuration processing model. The generated alignment report shows which records have complete flattening, ownership, and destination-route evidence and which still have gaps.