See what happens to your chart's hooks, CRDs, and setup work.

1. Know the phases, the dispositions, and who runs the work

A certified image renders your chart's ordinary objects without running its Helm hooks. For each hidden requirement it records a step: a lifecycle phase, who runs it, and whether it is automatic.

The phases are pre-render, preflight, pre-apply, post-apply, observe, and refuse. Each step also carries one of five reader-facing dispositions. observed means a passing receipt exists for that exact chart, version, preset, and target scope, and routed means the method is recorded but not run. per-target means the right method depends on your cluster. blocked means a prerequisite or evidence is missing, and refused means it was deliberately not run. The linked machine-readable sources use a finer vocabulary, including not-run and recipe-needed, so a per-chart view may show states beyond these five.

Every lifecycle action packet today is automatic: false. ConfigHub does not yet choose or run a chart-specific hook step for you. The certified-bundle steps below are a separate model, where a declarative, idempotent step such as CRD ordering can be automatic. The pattern stays observe, then execute, then emit a receipt. Read the disposition, supply what it needs, and run only the action that is actually supported. The step becomes observed once a passing receipt covers that scope.

Who runs it today is you, your cluster or controller, or, not yet, the product itself.

This follows what hook support means and the hook lifecycle strategy. Both name the same evidence with their own vocabulary, so read this page first and those two for the deeper detail.

2. Read the short answer and your practical choices

Short answer: the catalog renders your chart's objects without running its Helm hooks. Then, for each chart, it records what still has to happen.

That may be a setup step, a CRD ownership choice, a GitOps action where evidence exists, a target-specific decision, a blocker, or a refusal. The answer is chart-specific because Helm hooks are chart-specific.

These choices are how the catalog handles most real cases. It does not need one generic hook mechanism that treats every chart the same way. It needs accurate chart-specific answers, recorded inputs, and receipts where support is claimed.

Read the full guide for the source of this section.

3. See what a step tells you

• Where it goes. A lifecycle phase: pre-render, preflight, pre-apply, post-apply, observe, or refuse.
• Who runs it. You, your cluster or controller, or, not yet, the product.
• Whether it is automatic. The step's record says which exact implementation ran. A direct script result does not prove the Argo CD or Flux version of the same step. Top-level automatic stays false until every delivery path named by the claim has its own receipt.
• What is needed next. The target facts to supply, and the evidence required before the step can be called supported.

The machine-readable form is the lifecycle route actions: an agent reads actions.json and turns a row into a preflight, action, and observe plan. The route contract behind it is lifecycle routes. The per-chart view, each chart's steps, disposition, and whether a skill applies, is per-chart hooks, shown as colored cards.

Handle hooks and CRDs has the six steps that act on a plan, and the worked examples. It also says who owns each CRD, and how to stage target prerequisites.

4. See how a bundle carries a plan with the objects

A flatten-with-routes verdict names the companion artifacts a bundle must ship. Those are the steps of its plan, and they travel inside the bundle. How to apply the configuration then never depends on whoever happened to flatten the chart.

A step names the quirk class it discharges and states what breaks without it. It carries a declaration rather than a command: it says what must hold, not how one tool achieves it. The executedBy block lists the runtimes that can execute it and how each expresses it. It also carries automatic, which defaults to false and is earned by observation.

The first step is traefik's CRD ordering. Its verdict requires an ordering declaration for 25 CRDs: definitions first, with a wait for establishment, then everything else. Ordering is declarative and idempotent, so this step is marked automatic; a step that runs a Job is not, and stays manual until observed.

Schema: BundleRoute. The full spec also covers the Space guide and the boundaries that ship beside every step.

Hooks under GitOps

A Helm hook becomes a named piece of work, not an inherited Argo or Flux hook. For one chart the right answer may be a preflight check. For another it may be an Argo sync action, a Flux-compatible step, a target fact, or a blocker. The catalog should say which answer applies and what evidence exists.

Read the full GitOps adopter guide, and see routing hooks transparently for the pathway behind it.

5. Understand each tracked requirement, chart by chart

Use this table when a term is unfamiliar. Use the matrix when you need the exact status for one chart version and configuration.

6. Check what remains before deployment

A matching render is only the first check. The cluster may still need CRDs, a Secret, webhook readiness, storage, cloud identity, or a controller.

A recorded step does not mean it runs automatically. The chart page must say who runs it and link the result when that path has been tested.

A watch or blocked result needs action. Follow the stated setup, decision, or evidence link before deployment.