Change Proposals
Technical reference. This page is for integrations, advanced configuration, or platform operations. For portal tasks, start with the user guide.
A change proposal is a reviewable statement of intent: move a workload from the release that is active today (the baseline) to a draft candidate release. The proposal compares the two, records who proposed it and which versions it was written against, and keeps that record next to the release it concerns.
A proposal does not change anything by itself. It never writes release state, never copies a release, and has no “apply” step. The release decision stays on the release: approve and activate the candidate with the usual release approval and transition. Release approval is not blocked by a proposal, and a proposal’s review (when it is available) is a separate decision from the release approval.
Who can do what
Change proposals reuse the release permissions. No new permission exists.
| Action | Permission |
|---|---|
| Read and list proposals | release.view |
| Create, edit, submit, withdraw | release.create |
Withdrawing someone else’s proposal also needs workspace management rights.
Open a proposal
- Open the workload, or an asset’s Dependencies tab, and choose Propose change. From a Regions scenario, choose Propose change for … next to an affected release.
- Pick the baseline: the active release. Leave it empty only for a first release; if a release is already active for the lane, a baseline is required.
- Pick a draft candidate release of the same workload and environment, or create one from the form. Configure the candidate on the release itself, with the release binding routes.
- Give the proposal a title and summary.
A candidate release can have one open proposal at a time. Managed releases and workloads cannot be proposed against.
Draft, submit, revise
A proposal starts as a draft. Editing is protected against lost updates: a save carries the revision and the content hash you last read, and a conflicting save is refused so you can reload.
Submit freezes the revision against the candidate’s bound versions, the baseline’s pins and the candidate’s evidence. A submitted proposal is read-only. When changes are requested, an edit starts a new revision and the next submission freezes it again.
Baseline revalidation
The baseline is rechecked every time the proposal is read:
| Status | Meaning |
|---|---|
current | The baseline is still active and unchanged since submission. |
changed | The baseline’s bound versions differ from those frozen at submission. |
superseded | The baseline is no longer active, or a release became active after a proposal without a baseline. |
none | No baseline: a first release. |
A changed or superseded baseline leaves a requirement unmet and means the
differences shown may no longer describe the real change.
What the page shows
- What changes: binding differences between the baseline and the candidate (asset, runtime and connection bindings). Identical bindings are not listed.
- Target and dependency impact: the workload in scope, with a link to the declared dependencies.
- Evidence and decisions: the candidate’s evidence, the proposal’s own state, the release decision (the candidate’s state and its release approvals, read only), baseline revalidation and the requirements.
CLI and SDK
orqestractl proposal create --workload-id W --candidate C --baseline B --title "Tighten prompt"
orqestractl proposal get P
orqestractl proposal update P --revision 1 --content-sha256 H --summary "..."
orqestractl proposal submit P --revision 1
orqestractl proposal withdraw PThe Python SDK exposes the same verbs as client.change_proposals.
Every mutation is written to the governance audit trail with identifiers and hashes only, never the title or summary text.