Two-Cluster Helm-vs-Installer Kind Parity

This report tracks strict parity receipts that use two vanilla kind clusters: regular Helm on one cluster and cub installer render/apply on the other.

It is the cleanest live check for the narrow parity question:

New to cub? Install the cub CLI first. You can pull and render public catalog packages without an account. Commands that save or change ConfigHub data require you to sign in.

Under the same chart, version, values, and base variant, does regular Helm reach
the same live outcome as cub installer output?

pass: 130
watch: 3
blocked: 46
semantic parity pass: 155
semantic parity defects: 16
non-pass rows where semantic parity passed: 25
non-pass rows with related lifecycle evidence: 0

Non-pass rows are still useful when object parity passed. They usually point at target prerequisites, controller readiness, storage, hooks, or operating policy. Use the rerun plan for the next command and expected remediation:

data/live-parity-rerun-plan/summary.md

Non-Pass By Reason

How To Read Non-Pass Rows

The result column records the overall live command outcome. The semantic_parity column records whether regular Helm and cub installer produced the same Kubernetes object meaning. A non-pass row with semantic_parity=pass is not an object parity defect. It means the row exposed target, runtime, or lifecycle behavior that needs a route, observation, or support decision.

The related_lifecycle_evidence column links a separate lifecycle receipt when one exists. If a future row is non-pass while semantic_parity=pass, read it as a target, runtime, or lifecycle route to investigate before making a broader support claim.

Rows