Change Governance Datasheet

Approvals enforced, not hoped for. Approval-as-policy bound to the estate path - quorum, self-approval exclusion, change windows with audited overrides - a checklist frozen at creation, the approver sees why a change was raised, every decision in the history, and the reason a step failed on the step itself.

Key Highlights

  • ✓Approval-as-policy on your environment paths - quorum enforced, self-approval excluded by the platform, a checklist frozen at creation so no later policy edit can loosen a pending change.
  • ✓The approver sees why - the rationale, the recommendation the change implements, who raised it and in which tier, and the correlation chain behind an agent's work.
  • ✓Decision history - an approver reviews their own past decisions; the governance administrator reviews every decision, exportable line by line.
  • ✓Change windows with overrides that are explicit, permission-checked, and loudly audited.
  • ✓Notification mandates - a group that must be told is told, every member, no mute.
  • ✓Fingerprinted submission exports - a verifiable record of exactly what was submitted and approved, on every line of a multi-line checklist.
  • ✓Failure reasons on the step - when a workflow step fails, the reason is on the step in the GUI and the CLI, not only in the server log.

Change governance in OpsChain means the approval policy lives on the estate path where the change actually runs — so execution can never drift away from the approval, and changing your approval rules never means changing your automation. v5.6.1 adds the context an approver needs to decide, the history of decisions taken, and the reason a step failed on the step itself.

This datasheet covers the mechanisms (approval-as-policy with quorum and self-approval exclusion, a checklist frozen at creation, change windows with audited overrides, notification mandates, fingerprinted exports of every checklist line, approval gates), the approval context — who raised the change and in which tier, the rationale, the recommendation it implements, the correlation chain behind an agent's work — the decision history for approvers and the governance administrator, and how it all works with your CAB and supports your regulatory evidence.

What you can verify

  • opschain approvals show <run> -o json lists every line's approval rows and the rationale.
  • A policy edited while a change is pending does not loosen that change; it governs the next one.
  • opschain runs show <id> prints the reason under a failed step.

Download Change Governance Datasheet

Fill in the form below to access this resource.