What We Checked

Use this page to see which claims have evidence and which ones still need a chart, values file, or target-specific check.

First we check that cub preserves Helm's objects. Then we track scans, approvals, delivery, live checks, and limits separately.

Start with Verification · Read the matrix · Read the claims register

Generated at: 2026-07-30T12:38:02.000Z UTC · source: committed helm-expt evidence for this proof page.

Current Proof Counters

These counters are not one giant green badge. Each lane checks a different question, and production use still depends on target scope and fresh evidence.

199/199Render parity · Regular Helm output and cub installer package output match under recorded inputs.
198/199In-ConfigHub proof · Rendered objects have been uploaded, scanned, and exercised as ConfigHub Units.
148/199Local live · The package was applied to a local Kubernetes target and observed.
139/199GitOps/OCI live · ConfigHub-published OCI was pulled and reconciled by Argo in a live run.
139/199Live dual parity · Regular Helm, ConfigHub direct apply, and ConfigHub OCI/Argo reached the same semantic object outcome.
130/179Two-cluster kind parity · Regular Helm and cub installer were compared on two vanilla kind clusters.
126/199Complete core lane · Rows with render, ConfigHub, local live, GitOps/OCI, live parity, and two-cluster evidence.
0/199Semantic defects · Committed live parity rows where ConfigHub and Helm disagree semantically.

What Each Lane Proves

LaneQuestionEvidenceLimit
Render parityDoes cub installer preserve the Helm object set for this chart/version/base?Helm render receipt and installer comparison.Per chart, version, base, values, capability profile, and flag profile.
ConfigHub proofCan the rendered objects become Units, scans, safe ops, and receipts?ConfigHub proof receipts, function scan receipts, safe-ops receipts.Does not prove a GitOps controller or workload health by itself.
Local liveDoes this package apply and converge on a Kubernetes target?Observation receipt, workload checks, PVC/CRD/secret evidence where relevant.Usually local kind; target-specific production support still needs scope.
GitOps/OCI liveCan ConfigHub-published OCI be reconciled by Argo?Argo sync and health in the live parity receipt.A green sync is not enough unless runtime checks also pass.
Live dual parityDoes regular Helm reach the same live outcome as ConfigHub delivery?Strict live Helm-vs-ConfigHub parity receipt.Selected rows only; absence is backlog, not a failed chart.
Two-cluster kind parityDoes Helm on one vanilla kind cluster match installer output on another?Two-cluster parity receipt.Narrowest clean parity test; no ConfigHub/OCI proof unless separately recorded.
Lifecycle observationAre hooks, CRDs, webhooks, generated facts, or target prerequisites observed or routed?Lifecycle, hook, target-fact, and serious-chart receipts.Partial by design; some rows are routed, blocked, per-target, or refused.

Use Verification for the command map, Verification Lanes for lane meanings, and Chain Of Proof for the boundary between repo evidence, ConfigHub, GitOps, and live observations.

Serious Charts Are The Test

Hard charts are where mistakes hurt: kube-prometheus-stack, cert-manager, External Secrets, Argo Workflows, Argo Rollouts, stateful databases, and charts with hooks, CRDs, webhooks, generated secrets, storage, or target facts.

This is the expert/SRE problem. Before a fleet change ships, someone needs to know what it touches, what the cluster must already provide, which checks passed, how it will be delivered, and what the live system reported afterward.

For these charts, a green render is not enough. The page must say which prerequisites are required, which lifecycle route is selected, what the target observed, and whether the production scope is accepted, superseded, rejected, or still under review.

kube-prometheus-stack

High-fanout guide and production packet.

cert-manager and ESO

Lifecycle observations for CRDs, webhooks, and controller-populated fields.

Argo Workflows

Hook-delivered CRDs routed through the lifecycle boundary.

Argo Rollouts

Default and no-crds bases now have live Helm-vs-ConfigHub parity receipts.

Hooks

Top-100 hook dispositions separate observed, routed, per-target, and recipe-needed rows.

Sceptic Tests

A breaking chart is useful QA. It needs to become a test fixture, a named refusal, or a routed gap. It must not disappear into prose.

Use the problem chart issue template to send a public chart, values file, or catalog mismatch.

SurfaceWhat it answersOpen
Claims registerEvery public claim is backed, partial, planned, or refused.../data/claims-register/summary.md
Blast-radius accuracyPredicted affected objects are scored against actual rerender diffs, including published failures.../data/blast-radius-accuracy/summary.md
Synthetic torture suiteBreaker charts land in named pass, refusal, or route outcomes; silent outcomes fail.../data/torture-suite/summary.md
Environment matrixRenders are checked across timezone and locale cells for the measured corpus.../data/environment-matrix/summary.md
Hook dispositionsHook-bearing top-100 charts have observed, routed, per-target, or recipe-needed dispositions.../data/hook-disposition/summary.md
Master matrixEvery chart/version/base row carries lane status, source links, production scope, and next action../matrix.html

What This Does Not Claim

RefusalWhy it matters
No blanket chart supportEvery claim names chart, version, base, lane, and target profile.
No whole-values-space proofThe catalog proves named bases. Custom values must be rendered, checked, and recorded with receipts.
No universal hook executionHooks are inventoried and routed; execution is claimed only with live evidence.
No production claim from render parityProduction support requires target-scoped decisions and fresh receipts.
No signature-as-safety shortcutSignatures prove origin/integrity. Scans, policies, and live evidence carry safety claims.

Read the full refusal page or open the claims register.