Skip to main content

cwright propose

cwright propose <model> <variant> --kpi NAME --indifference X
[--replications N] [--out-dir DIR]

Applies a proposed change to a baseline model, then decides whether it helped. This is the command a search loop or an agent proposing model changes is expected to call: it verifies the change is well-formed before running anything, and only then measures whether it is actually an improvement.

The two verifications, in order​

  1. Is the transformation correct? variant.yaml is a variant document — a description of a change to apply to the baseline, not a full model — and it is validated as data before anything is simulated. If the proposal cannot be applied cleanly, propose fails here with a message naming what was wrong, and nothing is run:

    the proposal 'add a third scanner' cannot be applied:
    <problem detail>

    ⚠️ Nothing was run. This is a defect in the PROPOSAL, not evidence about the idea -- do not
    record it as a result.

    That last line matters: a proposal that fails to apply is not evidence the underlying idea is bad, only that this particular encoding of it is broken.

  2. Is it better? Once the proposal applies cleanly, propose runs exactly the same comparison compare does, between the original baseline and the resulting candidate.

Flags​

Same as compare — --kpi, --indifference, --replications, --higher-is-better, --out — plus:

FlagDefaultMeaning
--out-dir DIRtargetWhere to write candidate.json, the fully-resolved model produced by applying the variant. Written out so the exact document that was measured can be re-run and audited later — a verdict about a model nobody kept is not reproducible.

Output​

Progress is reported to stderr — the proposal's name, its rationale if given, and the model hashes of both the baseline and the resulting candidate — followed by the same comparison document compare produces, on stdout or --out.

Example​

add-scanner.yaml is the variant document being proposed:

name: "a second scanner"
rationale: "litho is the constraint at 94% utilisation"
changes:
- { kind: set_servers, resource: scanner, servers: 2 }
cwright propose model.yaml add-scanner.yaml --kpi cycle_seconds --indifference 3600