The workflows, end to end

The change lifecycle

A change moves through five governance states. The rules are enforced in the backend, so they hold whether somebody clicks a button, uses a keyboard, or crafts the request by hand.

1. Recording a change

An agent opens any Jira issue in a project where Change Guards is set up and fills in the panel. Nothing is written to the audit trail until they do — an issue nobody has recorded governance for is simply not governed, and the panel says so rather than pretending otherwise.

1. 1

   Open the issue

   The Change Guards panel appears on every issue in an enabled project.

2. 2

   Record the details

   Risk, change type, impacted service and the planned window. Times are read in your own timezone.

3. 3

   The chain records it

   A change.created entry is appended before the record is written, so a failure can never leave a change nobody recorded.

2. The approval round

1. 1

   Ask a named agent

   Pick from the people Jira says can be assigned this issue — so a candidate can never be somebody with no business seeing it. You cannot pick yourself.

2. 2

   Jira notifies them

   A comment goes on the issue and your own notification scheme does the rest. The app sends no mail of its own.

3. 3

   They decide, once

   Only the named approver sees Approve and Reject. A comment is optional; the decision and comment both go on the chain.

4. 4

   The change moves

   A rejection sends the change back rather than leaving it in review looking like it might still pass. Full approval unlocks the approved state — if no freeze blocks it.

3. Freeze windows and overrides

A project administrator declares a window with a name, dates and a reason. Every change already scheduled inside it is re-checked and flagged there and then.

1. 1

   Declare the window

   From Project settings → Change Guards. Existing changes inside it are marked freeze conflict immediately.

2. 2

   The change is blocked

   It cannot be approved. The panel names the window and its reason, so nobody has to go and look up why.

3. 3

   Reschedule, or override

   Moving the change out clears the conflict by itself. Otherwise a project administrator records an override with a written reason.

4. 4

   The override is narrow

   It is bound to the window it was granted for. Move the change into a different freeze and the conflict is raised again.

4. Running the CAB

Open the CAB workbench and work down it. The order is deliberate: what needs you, then what is blocked, then risk, then imminence. Approvals are given from the issue panel, so the meeting ends with decisions recorded rather than actions to write up afterwards.

5. Taking evidence

When an auditor asks, open Evidence, choose a scope and a format, and take the export. The chain is re-verified from genesis at that moment and the verdict is written into the file.