Configuration

Operators declare their tunable knobs in a config_schema; cairn layers the values and enforces who may set what.

Two scopes

Every knob has a scope, tagged in the schema:

• governance — safety-relevant thresholds (gate limits, PII backend, spend caps). Owned by the environment; a workflow or run that tries to set one is rejected at preflight and rendered read-only in the console.
• operational — tuning (batch sizes, sample counts, model choices). Settable per workflow and per run. Untagged fields default to operational.

Precedence

The effective value of an operational knob resolves as:

run override > run preset override > default preset > workflow config > environment profile > operator default

Governance knobs skip the middle: environment profile > operator default, always. Explicitly wired template inputs always beat config — config fills gaps, it never overrides the graph.

Inspecting the surface

cairn config workflow training/finetune        # every reachable operator's knobs,
cairn config workflow training/finetune --json # grouped, governance vs operational

The console shows the same composed surface in a workflow’s Configuration tab, where governance knobs appear locked with an env-owned badge.

Presets

A preset is a named, versioned bundle of operational config for one workflow: create presets in the Configuration tab, mark one as the default (it then applies to every run of that workflow, including scheduled and triggered ones), and pick a different one per run from the Run form. Saving a preset is fail-closed — any governance knob in it rejects the save. Schedules can pin a preset, and each run records which preset it ran under (config_preset on the run).

Operator authors can mark a field-level recommended value; the console surfaces it with a one-click “Use”.

Input presets are a separate concept: saved input payloads for the Run form (validated against the input schema), with no governance semantics.

Preflight — the dry-run verdict

Before anything runs, the same side-effect-free check is available everywhere:

cairn preflight training/finetune -i inputs.json   # exit 0 ready, 1 blocked

The verdict reports:

• blockers — missing inputs, unresolved operator bindings, governance config violations (the same fail-closed check the dispatcher enforces), template not found;
• gates — which steps will pause for approval (a heads-up, not a blocker);
• cost — the estimated spend;
• resolved_config — the effective layered config it would run with;
• warnings — advisory only, e.g. unhealthy connections (never blocks).

The console’s Run form runs preflight live as you type; POST /packs/{pack}/{template}/preflight serves the same verdict over HTTP; cairn run --dry-run additionally prints the compiled node DAG.