Current Proof Status

UNOFFICIAL/EXPERIMENTAL

Start here when you want to know what is proven today.

Plain-English Status

The current catalog is useful, but it is not a blanket production support claim.

Top-20:
  Good public catalog examples.
  Every chart has maintained bases, proof artifacts, and at least one live lane.
  Exact proof still depends on the chart/base/lane row.

Top-100:
  Good maintained proof corpus.
  Every chart has render parity against regular Helm.
  Most charts still need catalog review, useful variants, or selected live lanes.

Top-500:
  Good reconnaissance data.
  It shows where Helm pain appears across public charts.
  It is not a maintained recipe catalog.

Use the catalog when you want a chart and base to try. Use the lane summaries when you need to say exactly what has been proven for that chart/base. Use the production disposition pages when you need to decide whether a chart is ready for a specific production target.

Use the generated Claims Register when you want to check whether a public claim is backed, partial, planned, or explicitly refused.

Use the generated Master Catalog Matrix when you want the broad chart/version/base view in one browser page. It shows the current user route, strongest evidence, core-lane status, production scope, hooks, quirks, hard gap, and next action for each row.

For the remaining non-pass live rows, use the generated Live Parity Rerun Plan. The current queue includes target prerequisites, runtime/watch rows, image retention rows, render-input modeling work, and 16 two-cluster semantic parity defects that need inspection before they can become stronger live claims.

Product Frontiers

These are the main places where the catalog is useful but the product claim is still bounded. A chart can have strong render and live evidence while one of these frontiers remains open.

The sceptic-proofing work is also not finished. The claims register, blast-radius scoreboard, torture suite, and environment matrix exist today. Cluster-matrix, external reproduction, time-travel re-verification, and the upgrade gauntlet remain open proof work.

Find The Answer Fast

One generated file answers each common evidence question. Open the file; do not rely on prose summaries for counts.

Source Of Truth

The shortest generated status page is:

Status Dashboard

It summarizes top100 readiness, the retained top500 evidence map, proof lanes, hook and quirk residues, derived ConfigHub variants, GitOps/OCI, and live parity in one place.

The shortest generated answer for "can I use this chart?" is:

Chart Use Guide

It gives one row per top-100 chart and routes the chart to one of four user answers: use the public catalog now, promote after review, design a useful base variant first, or decide a named limitation before promotion.

The compact top-20 catalog status CSV is:

Top20 Catalog Status

It gives one row per catalog chart with supported base variants, strongest evidence, lane counts, hard gaps, and next action.

The top-20 base readiness table is the shortest answer for which base variant to try first:

Top20 Base Variant Readiness

It gives one row per top-20 base variant with start-here, try-with-proof, prerequisite, runtime, or hook lifecycle status.

The next80 queue is the shortest answer for which proof-grade non-catalog chart to promote, review, or improve next:

Next80 Action Queues

It separates the next80 into promotion review, limitation review, and user-shaped variant work, with source features and artifact links.

The refresh-survival report is the shortest answer for what happens when upstream Helm publishes a newer chart version:

Refresh Survival

It keeps supported versions pinned, lists upstream update candidates, and shows which candidate versions have only passed the render proof lane so far.

Production support is tracked separately from test evidence:

Production Disposition

It shows which top-20 charts still need explicit decisions for scan/gate warnings, lifecycle behavior, target facts, storage policy, RBAC, webhooks, extension slots, and operating policy before they can be called production-supported.

The shortest assignable production-support work queue is:

Production Support Work Items

It lists one row per concrete support task or keep-fresh item. A chart can have several rows because image, scan, lifecycle, runtime, and fresh-evidence work can be assigned independently.

The older chart-level production queue is still useful when you want one broad next action per chart:

Production Next Actions

The scan warning workdown is:

Scan Disposition Workdown

It routes external scan findings into concrete production work: fix in the installer base, add a resource policy, harden security context, explicitly accept or split privileged infrastructure, review runtime endpoints, or decide PDB policy.

The image digest workdown is:

Image Digest Workdown

It shows rendered image references that need digest resolution, image overrides, or explicit proof receipts before reproducible production OCI support.

The generated lane matrix is the authority for exact chart/version/base status:

Outcome Coverage

The generated outcome coverage is the easiest spreadsheet-oriented entry point for chart, base, derived variant, and feature status:

Outcome Coverage

The runtime/GitOps wave tracks the first Argo/OCI live rows:

Runtime/GitOps Wave

The target-bound derived variant summary tracks ConfigHub variants created from uploaded bases and then bound to live targets:

Target-Bound Derived Variants

The lifecycle observation summary tracks cert-manager and External Secrets checks that rendered YAML alone cannot prove:

Cert-Manager And External Secrets Lifecycle Observations

The Kube Prometheus Stack direct lifecycle proof records one complete fresh-install sequence: ten CRDs, the chart's certificate creation and webhook patch Jobs, 124 ordinary objects, readiness checks, and cleanup:

Kube Prometheus Stack Lifecycle Route Proof

The no-crds base also has an install-and-upgrade receipt through Argo CD and Flux. Both controllers installed the same 85.3.3 staged OCI digest, moved to the same 86.1.0 staged digest, replaced the completed setup Jobs, and passed the recorded CRD, certificate, workload, webhook patch, and runtime checks:

Kube Prometheus Stack Argo CD And Flux Proof

The controller receipt is limited to this version pair and target profile. It does not prove rollback, long-running soak, automatic ConfigHub route selection, or automatic post-success removal of every temporary hook resource.

The webhook certificate lifecycle summary tracks staged generated certificate material and staged CRDs for bases where render parity is not enough to prove the install contract:

Webhook Certificate Lifecycle Evidence

The cub-scout live witness watchlist records cases where ordinary live checks pass but strict rendered-object/live parity finds a target capability issue:

cub-scout Live Witness Watchlist

Accepted server-normalization rules for strict live witness checks are recorded separately:

Live Witness Normalization Rules

The hook/lifecycle boundary page separates hook queue rows from hook-like controller lifecycle observations:

Hook And Lifecycle Boundary

The extension-slot coverage page tracks charts with raw manifests, tpl snippets, sidecars, config blocks, add-on slots, or similar Helm inputs:

Extension Slot Coverage

The top-level catalog shows what a user can browse:

Catalog

How To Read The Status

The project has several levels of evidence:

recipe/package proof
-> ConfigHub proof
-> local live Kubernetes proof
-> GitOps/OCI live proof
-> live Helm-vs-ConfigHub parity proof
-> lifecycle observation proof for controller-owned or hook-like behavior

A row is only proven for a lane when the lane matrix says pass.

Production support is stricter than a passing proof lane. A chart can be render-equivalent, locally tested, and useful for demos while still not being production-supported. Accepted dispositions are review input; production support needs a final target-scoped decision.

Strict cub-scout witness checks are routed more conservatively than ordinary local live checks. A local live receipt can pass because the workloads converge, while the strict witness still finds that the live API did not preserve an authored field. Every committed strict-witness BLOCK must appear either in the watchlist or in the normalization log.

In data/live-e2e/top20-local-kind.csv, cubScout=observed means the row has committed cub-scout witness evidence summarized in the CSV. A blank cubScout cell means the row still has its ordinary observation receipt, but no committed cub-scout witness for that row. It is not a hidden pass or fail.

Receipt retention follows this policy:

• commit worked-example receipts and evidence needed by public walkthroughs;
• commit every receipt or evidence summary cited by a watchlist row;
• keep bulk transient run artifacts local when the generated summaries are the public surface;
• when a claim depends on live evidence, commit enough detail for a reader to understand the target, chart, base, result, and next action.

Current Interpretation

The repo has complete render-parity evidence for the current recipe/base rows. ConfigHub proof, local live proof, GitOps/OCI proof, and strict live Helm-vs-ConfigHub proof are tracked separately because each one proves a different outcome.

Current aggregate status:

chart/base rows:                          199
helm_template_vs_installer_setup:         199 pass, 0 missing
confighub_upload_variant_scan_safe_ops:   198 pass, 1 missing
local_kind_kubectl_apply:                 148 pass
confighub_oci_argo_live:                  135 pass
live_helm_vs_confighub_dual_compare:      135 pass, 53 watch, 10 blocked
two_cluster_kind_parity:                  121 pass, 10 watch, 47 blocked

Those counts come from the generated lane matrix: Outcome Coverage.

The missing rows are backlog. They are not failed rows. watch and blocked mean a committed receipt exists and the lane found a target, lifecycle, or fixture condition that still needs a decision or rerun.

GitOps/OCI live proof is tracked in two views:

• the broad outcome lane has 135 of 199 chart/base rows marked pass;
• the first runtime/GitOps wave has 11 committed controller receipts;
• 8 first-wave receipts pass and 3 are non-pass target-fit or runtime receipts;
• exact chart/base/controller status is in the generated runtime summary: Runtime/GitOps Wave.

Live Helm-vs-ConfigHub parity is selected-row evidence:

• The selected live comparison lane has 198 committed receipts.
• 135 rows pass, 53 rows are watch, and 10 rows are blocked.
• The lane currently has 0 ConfigHub/OCI semantic parity defect receipts.
• Watch and blocked rows are routed to target prerequisites, capability profiles, render-input modeling, image retention, runtime readiness, or GitOps controller review before a stronger live claim is made.
• Across the full 199-row lane matrix, use the generated outcome coverage to distinguish pass rows, committed non-pass receipts, and rows without a pass.
• The comparison checks regular Helm against ConfigHub delivery and records the expected installer-added Namespace object and any semantic object diffs.
• Exact chart/base status is in the generated summary: Live Helm-vs-ConfigHub Parity.

Strict two-cluster Helm-vs-installer parity now has 178 committed receipts:

• 121 rows pass;
• 10 rows are watch;
• 47 rows are blocked;
• 153 rows have semantic object parity;
• 16 rows currently report a semantic parity defect.

Use the generated rerun plan for the next command and expected remediation: Live Parity Rerun Plan.

For the shortest active queue, use: Active Proof Queue.

The current rerun queue has 119 rows: 62 watch rows, 57 blocked rows, 63 ConfigHub/OCI comparison rows, 56 two-cluster kind-parity rows, and 16 semantic parity defects. One row is documented as resolved by a separate useful base and is no longer active rerun work.

Production support decisions are now explicit for the top-20 catalog:

• 17 of 20 top-20 charts have supported target-scoped proof scopes.
• 2 of 20 top-20 charts are superseded deprecated source charts and remain catalog proof evidence only.
• 0 of 20 top-20 charts have rejected target-scoped proof scopes.
• 1 of 20 top-20 charts has a draft support decision.
• 19 of 20 are production-review-ready by pre-review disposition receipt.
• 1 of 20 still has a blocked pre-review production disposition.
• 105 production-disposition receipts are accepted across 20 charts.
• external scan work has 0 remaining mutable-image rows after the current supported-base image pinning pass.
• the remaining high-priority scan rows are routed to explicit privileged infrastructure or security disposition work, not to simple image-pin fixes.
• A supported target scope is still narrow: it covers the named chart, base, target, delivery path, accepted risks, and live evidence rule only.

The top-20 production queue has one remaining pre-review disposition blocker: cert-manager needs target-fact preflight closure. Vault is currently a draft target-scoped support decision for the default base; its dev-mode base remains documented as local/demo evidence rather than a production support path. The active support view is grouped from the current target-scoped decisions. Workstreams can overlap: one chart can need image, scan, lifecycle, and fresh evidence work before it becomes production-supported for a target scope.

Use the target-scoped decision table for exact blockers and next actions: Production Support Decisions.

For the plain-English path from review-ready to production-supported, see the user guide: Production Support Decisions.

Use the generated production disposition table when you need the pre-review receipts and accepted dispositions: Production Disposition.

Use the scan workdown when the question is what kind of work a scan warning represents: Scan Disposition Workdown.

Use the detailed disposition plan when you need the accepted receipts, owners, required evidence, and unblock rules: Production Disposition Details.

Use the generated support work-item queue when you want assignable production tasks: Production Support Work Items.

Use the generated disposition queue when you want the older one-row-per-chart production action: Production Next Actions.

Lifecycle observation proof has started:

• 11 public top-100 source-scan rows contain Helm hooks.
• 5 maintained hook queue rows now have hook route receipts.
• 5 of those 5 queue rows have lifecycle observation receipts.
• 0 of those 5 queue rows have only partial install-lifecycle observations.
• cert-manager default and crds-enabled pass lifecycle checks for its startupapicheck hook route, CRD ownership policy, startup API readiness, webhook CA bundle injection, and server dry-run.
• External Secrets default and no-crds pass lifecycle checks for CRD ownership policy, webhook CA bundle injection, controller-populated webhook Secret data, and server dry-run.
• These receipts demonstrate the lifecycle-observation pattern. They do not imply that all Helm hooks or controller-owned runtime behavior are supported automatically.

Use the hook boundary report for the current route-selected versus lifecycle-observed split: Hook And Lifecycle Boundary.

Target-bound derived ConfigHub variant proof has started:

• The generated target-bound derived variant summary shows the current pass and blocked rows: Target-Bound Derived Variants.
• NGINX-prod-us-east was created from a clean uploaded NGINX http-clusterip base with cub variant create --target, applied to a ConfigHub OCI target, reconciled by Argo CD, and observed as a live NGINX Deployment in Kubernetes.
• NGINX-customer-acme-prod repeats that same path for a customer-derived NGINX variant from the reviewed http-clusterip base.
• MetricsServer-prod-us-east proves the same target-bound path for a cluster-service chart; the receipt records Deployment, Service, and APIService availability.
• Prometheus-prod-us-east was created from a clean uploaded Prometheus server-only-ephemeral base with cub variant create --target, applied to a ConfigHub OCI target, reconciled by Argo CD, and observed as a live Prometheus server Deployment in Kubernetes.
• Prometheus-staging-eu-west repeats that same target-bound path for a staging derived variant from the same reviewed Prometheus server-only-ephemeral base.
• These receipts prove the derived-variant operating path for a small web chart, a cluster-service chart, and a server-only observability chart across production, staging, and customer-derived variants: clone the reviewed base, bind a real target, apply the cloned workload Units, and record Argo/runtime evidence.
• Redis-staging-eu-west has a blocked target-bound receipt. The work order asks for a namespace change and Redis Secret delivery, but those are not yet represented as checked post-clone mutations or secret/fact bindings in the derived variant path.
• The other derived-variant receipts remain intended-state clone/link evidence until they have target-bound live receipts.

For the details, read the generated summaries rather than copying numbers from this page.

Useful Next Pages