Browse Docs
Catalog
Config
Stacks
Operate
Docs

Configuration decisions

A configuration check can report several findings. Before a configuration is kept or promoted, someone needs to decide what happens to each one. View source markdown.

A ConfigurationDecision records that answer for one exact object set:

  • accepted-fix: the accepted candidate contains a named correction;
  • approved-exception: the finding remains for a limited scope and until a stated review date;
  • rejected: the candidate must not continue.

The record links each decision to the changed fields and evidence. An exception must name where it applies, where it does not apply, its conditions, and the date when it must be reviewed again. A changed object digest or destination requires a new decision.

Keep different checks separate

Local checks help before signup and remain advisory. ConfigHub validates a stored revision and can use managed controls to block delivery. Destination tests, delivery receipts, and live observations answer later questions.

Approving a decision record does not hide a local finding, turn a local result into a ConfigHub control, or approve a production workload. The record keeps these authorities separate so a reader can see exactly what was checked.

The public schema is configuration-decision.schema.json. The first complete example follows AI-written NGINX values through six accepted fixes, one scoped exception, ConfigHub retention, development-to-staging promotion, and two Argo CD test deployments. Read the worked decision chain.

Generated from the committed markdown file docs/reference/configuration-decisions.md. The source file is the authoritative version.