UNOFFICIAL/EXPERIMENTAL
This page explains how helm-expt fits the broader Generative GitOps idea: configuration is increasingly generated by tools and AI agents, so the output must be captured, checked, bounded, delivered, and observed instead of trusted because a generator produced it.
helm-expt is the Helm-facing proof of that model. It does not prove the full future product by itself.
Read it as the working import slice: Helm remains the source generator, but the rendered objects are captured once, checked against Helm, held as ConfigHub data, routed into base and derived variants, and then delivered or observed where the current evidence exists.
What The Model Expects
A Helm or GitOps user reading about Generative GitOps should expect these properties:
| Property | Meaning |
|---|---|
| Generated once | Helm, Kustomize, CI, or an agent can generate the initial config, but the generated object set is captured and checked before use. |
| Held as data | The rendered objects become queryable, versioned desired state, not only files waiting to be re-rendered. |
| Proven | A machine can check what was rendered, what changed, what was delivered, and what was observed. |
| Bounded | A change has a known blast radius before it reaches a target. |
| Continuously delivered | Existing Argo or Flux controllers can still pull OCI artifacts and reconcile clusters. |
| Observable | The model records what the cluster actually did, with freshness and target scope. |
| Reversible under authority | Authorized live fixes can eventually flow back into desired state instead of being treated only as drift. |
What Helm-Expt Proves Today
helm-expt strongly proves the first half of the model for public Helm charts:
| Property | Current evidence |
|---|---|
| Generated once | Each recipe pins chart source, dependencies, values, capability profile, and generated facts. |
| Helm-equivalent render | Render parity compares regular Helm output with the cub installer package output. |
| Held as explicit objects | Rendered Kubernetes objects are stored under recipe revisions and can be uploaded as ConfigHub Units. |
| Base variants | Supported bases make render-time choices visible, such as CRDs on/off, generated Secret versus existing Secret, storage mode, or ingress shape. |
| Post-render variants | ConfigHub variants can clone and refine uploaded Units for environment, region, customer, target, labels, approvals, links, and observations. |
| GitOps handoff | Selected rows prove ConfigHub OCI delivery through Argo or Flux. |
| Live evidence | Local kind, two-cluster parity, live Helm-vs-ConfigHub parity, and runtime/GitOps receipts record what happened on real clusters. |
| Hard chart prerequisites | CRDs, Secrets, webhooks, APIService, hooks, generated facts, and lifecycle behavior are routed as explicit target facts, lifecycle policy, receipts, or blockers. |
The strongest current example is kube-prometheus-stack. It has high object count, CRDs, webhooks, RBAC, hooks, generated facts, target prerequisites, GitOps/OCI evidence, and live runtime proof.
What Is Still Partial
These are not complete product claims yet:
| Frontier | Current status |
|---|---|
| Field-complete provenance | Blast-radius prediction is scored by a generated accuracy harness: 13 measured cases, 13 passing, 0 failing, and 0 unmeasured value-source rows. The claim remains per measured case; not every rendered field in every chart has provenance. |
| Full change authority | ConfigHub can record and gate operations, but the repo does not yet prove a complete per-field authority model for every agent or user. |
| Reverse live-to-desired flow | Live observations are recorded. Authorized live fixes flowing back into desired state are still future product work. |
| Universal hook execution | Hooks are inventoried, routed, observed, refused, or marked per-target. This is not a claim that every Helm hook in the top-100 runs automatically. |
| Fleet-wide bounded propagation | Derived variants, blast-radius cases, promotion examples, and a first Redis fleet blast-radius demo exist, but a complete fleet propagation product is still being built. |
| Signatures as trust | The claims register enforces this as reviewer discipline: no evidence means no current claim, partial stays partial, and refused claims stay visible. Signatures still prove integrity and transport only within a named signer, authority, and verification context. |
The Paper's Three Examples, In Helm-Expt
The paper illustrates the model with three scenarios. Here is where each one stands in helm-expt today, including the two that are still frontier. Closing these is tracked in issue #974.
| Paper scenario (paraphrased) | In helm-expt today | Evidence / gap |
|---|---|---|
| 1. Checking a generated change is a query, not a review. Ask the system what changed, under whose authority, and with what blast radius instead of relying only on manual diff review. | Strong for import and variants; partial for governed promotion. The rendered object set, render parity, variant lineage, and the dev-to-prod compare/diff are queryable evidence. | Master Catalog Matrix, per-revision receipts, and the Redis dev-to-prod promotion. Gap: the server-side promotion answer is capped at watch by ConfigHub #682 (160 cells), tracked as step 1 in #974. |
| 2. A generated fix to the live system sticks. An authorized live change flows back into desired state instead of being overwritten as drift. | Frontier, not yet demonstrated. Live state is witnessed by cub-scout receipts, but the reverse flow is not yet proven. | cub-scout workloads-converged and object-set-matches receipts witness live state. Gap: live-to-desired reconciliation under authority, tracked as step 2 in #974. |
| 3. A fleet-wide change shows its blast radius before it happens. Propagate across environments, see exactly what it touches, and stop at overrides. | Partial, with a first Redis fleet demo. Variant edges are recovered, one governed dev-to-prod promotion carries override protection, blast radius is measured on 13 of 13 recorded cases, and Fleet Blast-Radius shows how Redis environments are shielded by overrides. | Blast-Radius Accuracy and Fleet Blast-Radius. Gap: more charts, more value paths, and a live tie between the Redis fleet and ConfigHub promotion, tracked as step 3 in #974. |
The point of listing the misses next to the hits is the same as the rest of this page: a scenario the model cannot yet demonstrate is a named frontier with a tracked route, not a silent omission.
Sceptic-Proofing Status
The sceptic work is useful, but it is not complete. 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. The purpose is to turn reasonable attacks into fixtures, receipts, or explicit refusals:
| Attack question | Current evidence | Limit |
|---|---|---|
| Did a value-source map predict the real blast radius? | Blast-Radius Accuracy | 13 measured cases are scored today: 13 pass, 0 fail, and 0 value-source rows are unmeasured. The claim is still limited to recorded cases and should expand across more charts and value paths. |
| Does rendering change across timezone, locale, or flag profiles? | Environment-Determinism Matrix | The current matrix covers one platform, one Helm version, and four chart versions. |
| What happens when a chart is designed to break the model? | Synthetic Torture Suite | The fixture suite is intentionally small and should grow as new failure modes are found. |
| Which public claims are backed, partial, planned, or refused? | Claims Register | Partial claims stay partial until coverage expands or the product boundary changes. |
This is the right posture for the project: a chart or option that breaks the model should become a public test case with a named result, not a hidden exception.
Where To Check The Current State
Use these generated surfaces instead of relying on prose:
| Question | Start here |
|---|---|
| What is the state of one chart, version, and base? | Master Catalog Matrix |
| Can I use this top-100 chart today? | Chart Use Guide |
| Which public claim is backed, partial, planned, or refused? | Claims Register |
| Which outcome is promised and how is it tested? | Outcome Evidence Contract |
| Which GitOps/OCI rows have live receipts? | Runtime/GitOps Wave |
| Is blast radius measured or assumed? | Blast-Radius Accuracy |
| Where are hooks, CRDs, webhooks, and prerequisites tracked? | Current Proof Status and Target Prerequisites |
The Honest Claim
helm-expt proves that public Helm charts can be imported into a visible, variant-aware, receipt-backed ConfigHub workflow without changing the intended semantics of supported bases.
It is already useful for:
- seeing exactly what Helm produced;
- comparing
cub installeroutput with regular Helm; - choosing maintained base variants;
- uploading rendered objects as ConfigHub Units;
- delivering selected bases through OCI/GitOps;
- recording target facts, lifecycle prerequisites, and live observations;
- exposing gaps as
todo,watch,blocked, or refused rows.
It is not yet the full Generative GitOps product. The next product work is to make provenance, authority, bounded changes, fleet propagation, and authorized live-to-desired reconciliation feel as simple as installing a supported chart.
The route to closing that gap, so a reader of the paper can trace all six principles and all three scenarios to evidence or a named frontier, is tracked as a P1 in issue #974.