Plan an approval guardrail for production patching

Outcome: a production patch request waits for an authorised person before any change runs.

This example shows the structure of a knowledge-base guide. The policy below is illustrative, rather than an executable configuration or a description of final product screen labels.

Before you begin

• Identify the production systems covered by the rule.
• Name the administrator who owns the workflow and the people allowed to approve it.
• Agree a maintenance window and a recovery procedure.
• Use a test environment to verify the workflow before applying it to production.

Define the guardrail

1. Choose the action. Scope the rule to applying patches. Avoid bundling unrelated actions under one approval.
2. Identify the targets. Use an agreed inventory group or environment tag. Check its membership before testing.
3. Require approval. Route the request to named approvers and define an expiry time.
4. Set the timing. Require the approved action to remain inside the maintenance window.
5. Define the evidence. Record the request, affected systems, decision, approver and verification result.
6. Plan recovery. Document how an operator can stop or recover from an unsuccessful change.

Example policy

The following is a planning example. Adapt it to the configuration supported by your deployment.

workflow: production-patching
scope:
  environment: production
action: apply-patch
approval:
  required: true
  approver-group: it-operations-leads
  expires-after: 2h
maintenance-window:
  day: Sunday
  start: "02:00"
  end: "04:00"
  timezone: Europe/Zurich
on-expiry: do-not-run

Specify a timezone explicitly so every administrator interprets the window consistently.

Verify the behaviour

Test an allowed request, a rejected request, an expired request and a request outside the maintenance window. Confirm that none of the rejected or expired requests causes a change.

For an approved test, inspect the evidence record and verify the actual state of the target system. A completed workflow is not sufficient proof that the patch achieved its intended result.

Troubleshoot an unexpected result

If the request reaches the wrong approver, review group membership and rule scope. If it runs at an unexpected time, check the configured timezone and any overlapping rules. If verification fails, stop further rollout and follow the recovery procedure.

Contact the Simorin team with the workflow name, approximate event time and a short description. Request a secure exchange method before sharing sensitive system details.

Next steps

Review the results with the administrators who will operate the workflow. Keep production patching behind approval until your team is ready to review a different policy.

Read Managed autonomy for the broader approach to permissions, approvals and evidence.