Rich Plan Approvals
A basic approval asks whether a workflow may continue. A rich plan approval binds the decision to one durable proposal: its review payload, artifacts, workflow definition, required roles, and quorum. Use it for infrastructure plans, database changes, or AI-proposed remediation where reviewers must see the exact proposed effect.
Build and review a proposal
These flow items belong inside <steps>:
<step id="buildReview">
<script>
return { review: {
title: "Deploy payments API",
summary: "Apply the verified release plan.",
risk: "high",
facts: [{ label: "Environment", value: "production" }],
changes: [{ action: "update", target: "deployment/payments-api", summary: "Deploy release 42" }],
checks: [{ name: "Integration tests", status: "passed" }],
artifacts: []
} };
</script>
</step>
<approval id="approveDeployment" review="{{context.steps.buildReview.review}}" approvals="2" required-roles="production-owner security-owner" timeout="24h" on-timeout="reject">
<when-approved>
<step id="deploy"><script>return { approved: true };</script></step>
</when-approved>
<when-rejected>
<step id="declined"><script>return { approved: false };</script></step>
</when-rejected>
</approval>The review must be an exact reference to already-completed durable step output. Replace the illustrative deploy body with the separately authorized effect. Include a durable artifact reference when reviewers must authorize exact file bytes.
Configure reviewer authority
Roles and verified provider identities come from an operator-owned Reviewer Directory, not from workflow source or callback fields:
woml run workflow.woml --reviewer-directory ./reviewer-directory.json
woml get <run-id> --jsonThe approval resolves only when enough distinct principals vote and all required roles are represented. A rejection or timeout settles the same durable decision. A notification is not proof of identity; configure the provider or trusted gateway correctly.