Both pages run in the browser. They do not send your YAML to ConfigHub, an AI service, or Kubernetes. You may download the exact objects and review record, then give them to Claude, Codex, or another assistant you already use.
Check my config also downloads one workshop-result.json. It contains the exact candidate, optional comparison, optional Catalog source and intent record, review, file hashes, and canonical object-set identity. See the anonymous browser guide.
Keep four questions separate
Ask the assistant to answer these in order:
- What do I have? Inspect the supplied source, snapshot, package, OCI, or exact files. No Catalog match or deployment is required.
- What will it produce? Run the source-native tool and retain the exact objects, or record that materialization is a no-op for literal YAML or OCI.
- Can this destination accept it? Check the exact candidate against current destination facts. This needs destination access but not a deployment.
- Did it work? Check the exact delivered revision with the controller, resource, workload, runtime, drift, or rollback evidence required by the claim.
The review stores evidence state separately from result state. If a required component was never deployed, a dependent resource check is blocked or not run. It is not a failed configuration or workload result. This rule applies to Helm, AICR, Timoni, Kubara, Sveltos, OCI, and Kubernetes YAML.
Check a new configuration
- Open Check my config.
- Choose the practical question you need answered.
- Add the rendered Kubernetes YAML. Add the current or trusted YAML when you want a comparison.
- If the configuration came from the Catalog, add its
BaseVariantRecord. This adds the known source, prerequisites, hooks, CRDs, policy, and evidence status. - Run
cub check --format json --output cub-check.json <rendered-path>when you want the shared local checks. Add that result to the page. It is accepted only when it names the same canonical object set. - Run the browser check and download
candidate.yamlwithworkshop-review.json.
The browser parses the YAML as data. It inventories the objects, hides formatting-only changes, checks a small set of manifest risks, and lists what it did not test. It does not run the source tool, contact a cluster, execute hooks, or prove application health.
The generated AI prompt asks your assistant to confirm the file hashes, keep private inputs local, separate computed findings from Catalog evidence, retain stable scanner finding IDs, and write any proposed fix to a new file. The assistant does not get to turn an unrun check into a pass or a local advisory result into ConfigHub validation.
Review a promotion
Open Promote my config after Check my config, or load the current and proposed YAML directly.
For a source-aware result, provide four files:
| File | What it tells the review |
|---|---|
| Old source render | What the old chart or source produced before later edits |
| Old accepted configuration | What you actually accepted and kept |
| New source render | What the new chart, values, or source produces |
| Proposed accepted configuration | What you intend to move |
The result separates source changes from later object edits. It marks a field for review when the source and a later edit both affect it. It also carries Catalog prerequisites and lifecycle work into the test plan when a BaseVariantRecord is supplied.
Add one result per staging or fleet target in this form:
staging-eu | pass | rollout and smoke test passed | sha256:...
prod-us | not-run | waiting for approval |The digest must match the proposed configuration. A passing target does not make an untested target pass, so a mixed fleet remains partial.
Keep the accepted result in ConfigHub
The free result remains useful as local files or OCI. Use ConfigHub when the accepted objects, source record, variants, approvals, release digest, and target results need to remain connected for a team.
The promotion page generates current cub commands. It starts with cub variant upload --dry-run to preview a source refresh and cub variant promote --dry-run -o mutations to preview each downstream Space. Review those outputs before any write. After approval, record the source refresh, promote the same candidate, publish the release OCI, and add each target result to the review.
The generated upload annotation carries the same canonical object-set hash as the browser or CLI result. This does not replace the OCI digest or ConfigHub revision identity. It connects the accepted Kubernetes objects across the handoff. See the generated Helm and plain-YAML command contract.
ConfigHub records desired configuration. A successful upload or promotion does not by itself prove Kubernetes admission, hook execution, application health, data migration, or rollback of external effects.
For a complete measured example, see Test candidates before promotion. It runs three exact NGINX configurations on one target, rejects the candidate that does not meet the destination requirement, selects the smallest passing candidate, and checks that ConfigHub and Argo CD use that same object set.