The complete corresponding model - what "ConfigHub replaces Helm" must mean

Status: DOCTRINE (2026-06-02). The north-star claim of the catalog and the contract every chart must meet.

The claim

For any public Helm chart (plus its Kustomize / overlay customization), ConfigHub + cub installer provides a modular, executable model that reproduces the chart's result and that a user can read, use, and verify - without running the chart's templating engine.

This is the product thesis. The catalog only earns it if every chart ships a complete corresponding model, not a prose promise. This doc defines "complete" precisely enough to be machine-checked, and - critically - honestly, so the claim survives an adversary.

What "100%" must mean (and must not)

"100%" is a claim about the rendered result and the accounting of behavior - not a claim that a static file reproduces live, cluster-dependent dynamism by itself.

100% means, per chart:

1. Render-equivalent - for every supported variant, cub installer setup output ≡ helm template output (modulo declared support objects), proven by a digest-bound equivalence receipt the user can re-run.
2. Behaviorally complete (no silent gaps) - every Helm behavior the chart uses is either absorbed into the model (named home + policy + proof) or explicitly dispositioned. The HelmPlan carries zero unknown and zero unhandled. Render-time dynamism becomes explicit model elements; live / lifecycle behavior becomes policy + receipts or an honest blocker:

1. Variant-complete - the model covers how users actually install/vary the chart (default plus the meaningful render-time variants), so a Helm user replacing their usage finds their shape, not only default.
2. Readable - a per-chart artifact map answers: which variant do I install, what will it create, what differs between variants, and what's the catch.
3. Usable - executable end to end (cub installer setup / render / package), reproducing the objects without the chart's templating engine.
4. Verifiable - machine-checkable receipts (equivalence / render / scan / gate) + npm run verify; the user can re-run the equivalence proof themselves.
5. Honestly scoped - catalog-status.yaml declares the support scope (local-test / production) and names every blocked or deferred part.

100% does NOT mean a static model silently re-executes lookup, runs hooks, or resolves .Capabilities on its own. Those are made explicit (facts / profiles / policies) or blocked. A chart whose core function is arbitrary post-render templating may be honestly un-modelable in full - and saying so, with the boundary named, is a complete model. The blocked / operator-decision disposition is part of completeness, not a failure: an adversary cannot find a behavior we silently dropped, because there are none - every behavior is either absorbed or named.

Why the honest version is the strong version

A breakable claim ("100% of any chart is silently replaced") dies the first time a reviewer finds a lookup or a hook we glossed over. The honest claim ("100% rendered-equivalent for declared contexts + 100% of behaviors absorbed-or-named + every receipt re-runnable") cannot be broken that way - and it is a bigger product statement: not "we re-ran Helm," but "we turned Helm's hidden behavior into an explicit, reviewable, verifiable model."

Where we are vs. the contract

The current measured state is in data/model-completeness/summary.md.

This report is a model-support view, not the whole live outcome. Level 2 means the chart has a complete, honest, reproducible model for its declared scope. The full catalog outcome still needs the outcome coverage:

What this command does. cub installer is a released, open-source plugin for the cub CLI. cub installer setup pulls a catalog package and writes its Kubernetes files locally. It does not apply those files to a cluster; use kubectl, Argo CD, or Flux for delivery. The generated scripts stop before doing any work when the plugin or kustomize is missing.

default and declared main choices
-> Helm-equivalence and installer setup
-> ConfigHub upload, scan, clone/check, and safe-ops proof
-> live Kubernetes observation
-> ConfigHub OCI through Argo/Flux
-> live Helm-vs-ConfigHub parity

Recommended extra variants are an enhancement until they are declared as supported choices. Once a choice is declared supported, it must be tracked as its own chart-recipe-variant row with the relevant lane evidence.

Current headline:

supported (Level 2): 100 / 100
variant-rich:        54 / 100

supported (Level 2) means the six support criteria pass for the declared scope: render equivalent, behavior accounted for, readable, usable, verifiable, and honestly scoped. Variant richness is now reported as an enhancement metric, not as the support gate.

The current top-100 should be read like this:

So the catalog is no longer "20 complete and 80 incomplete." A more accurate reading is:

100 charts have a supported proof model for their declared scope.
20 charts are public catalog-supported for local-test.
54 charts have more than one base variant.
46 charts are still default-only.
25 charts have a hard gap for at least one recommended extra capability.
16 charts have supported target-scoped production support decisions.
2 charts are superseded deprecated source charts.
2 charts have rejected default bases with concrete production follow-up routes.

The hard-gap count is about missing recommended capabilities, not total chart failure. A chart can have a working, supported default recipe while still missing a useful existing-secret, no-crds, or HA path for a specific variant.

The delivery program (to actually earn the claim)

1. Keep the verifier check green - npm run completeness:verify scores the 100 charts and fails if support criteria regress.
2. Use the gap reports as work queues - data/chart-facts/summary.md, data/variant-backlog/summary.md, and data/quirk-review-queue/summary.md explain which charts need capability, variant, or review work.
3. Build variant richness deliberately - close the 46 default-only entries and the 29 hard-gap entries without treating every possible Helm value as a catalog promise.
4. Add production dispositions - local-test support is not production support. The production lane is tracked in data/production-disposition/summary.md.
5. User-verifiable surface - each chart's map carries the exact cub installer commands plus the re-runnable equivalence check, so a user can read → use → verify the corresponding model themselves.

Completeness is the admission bar: a chart is catalog-supported only when it meets this contract for its declared scope; otherwise it is a candidate, with the gap named.

Relationship to the other doctrine docs

• catalog-doctrine.md defines the customization surface (default + parameterized + standard variants).
• complete-corresponding-model.md (this doc) defines completeness + equivalence + verifiability per chart.
• agreed-execution-plan.md "Helm Pain Absorption" is the behavior-accounting mechanism this contract enforces.

Sources

agreed-execution-plan.md (Helm Pain Absorption; "no unhandled pain points"), catalog-doctrine.md, next-execution-plan.md, and the generated status, outcome, and live-parity data under data/.