10.5 Lab: run a change advisory board on OpsChain

packs:change-governancepacks:security-governance

After this you can: compose approval policies, maintenance windows, asset owners, waivers and the evidence ledger into a working change advisory board practice — with no new verbs.

Before you start — tick each one:

• Lesson 10.1 — Approval policies and the change funnel (opschain learn 10.1)
• Lesson 10.2 — Asset owners and impacted-owner approval (opschain learn 10.2)
• Lesson 10.4 — Waivers (opschain learn 10.4)
• Lesson 5.6 — Maintenance windows (opschain learn 5.6)

In the GUI: Inbox → Approvals is the board's queue; the Audit history screen is its minutes.

A change advisory board traditionally reviews changes in a meeting and records its decisions in minutes. OpsChain inverts that: the board's standing decisions become policy enforced on the path where changes run, the meeting reviews only what policy cannot decide alone, and the minutes write themselves. This lab composes the pieces the module taught into that practice. Every step uses a command you have already run; if one does not show what the lesson that taught it showed, re-read that lesson before going on.

1. The standing decisions become approval policies

Most of what a board decides is the same decision repeated: production changes of this kind need these approvers, at this quorum, and never the requester's own signature. Spell each such decision once as an approval policy (lesson 10.1) — a path pattern, optional action patterns and metadata predicates, the approver sources, a quorum of distinct identities, and self_approval left at its default of false. From then on the platform holds the line in the funnel: a covered change cannot run until the policy is satisfied, and no workflow author can code around it.

Write one policy for "production changes need two approvers from the release managers group", propose a change it covers, and confirm the change holds in pending_approval exactly as lesson 10.1 showed.

Where the right approvers depend on what the change touches, use impacted-owner approval (lesson 10.2) instead of a static list — the approver set resolves per change. Declare an owner on one subtree and propose a change under it: the all-of owner line appears on the held change.

2. The calendar becomes windows

The board's "not during quarter close" and "weekends are frozen" decisions are maintenance windows (lesson 5.6) on the subtrees they protect: new work refused by name, trigger firings parked, and any override an audited, attributed act rather than a quiet exception. Schedule one window over the subtree your policy covers and show, from the events feed, a firing deferred under it.

3. The meeting reviews the exceptions, not the routine

With the routine enforced as policy, the board's attention goes where it is needed: proposed changes waiting in the funnel, break-glass uses since the last review, overrides performed under windows, and waivers (lesson 10.4) approaching expiry. Each of those is a query against the record, not a report someone compiles. Produce the four lists from the commands the lessons taught — the held changes, the break-glass events, the window overrides, the waivers expiring within thirty days.

4. The minutes are the ledger

Every decision the funnel makes — who proposed, who approved, what was released, what refused and why — is already on the events stream and, with packs:security-governance, the evidence ledger (lesson 11.2). A control such as "production changes require board approval" links to the policies that enforce it, so the auditor's question is answered by the system that did the enforcing. Export the submission record for the change you held in step 1 and read the decision history out of it.

Check yourself

• Name the five standing elements of a working board posture on OpsChain, and the lesson that taught each.
• For the change you held in step 1: who proposed it, who approved it, and where did you read that from without compiling anything?

What you learned

• A working change advisory board posture on OpsChain has an approval policy for every standing decision, strict where lapse must fail closed.
• Impacted-owner resolution wherever the approver depends on the asset.
• Windows over the frozen periods, with overrides reserved and audited.
• A review rhythm that reads the funnel, the break-glass record and the expiring waivers.
• A named control binding the posture to the evidence that proves it.

Next: this closes the module Change governance — back to your track (opschain learn).