Everything it does, in detail

The change record

A change record is a Jira issue. Change Guards does not copy it, mirror it or replace it — it adds the governance facts Jira has no field for, keyed to that issue:

• Risk — low, medium or high.
• Change type — normal (assessed and approved before it is scheduled), standard (pre-authorised, recorded rather than re-argued) or emergency (restores service now; approval is captured alongside, not before).
• Impacted service — what breaks if this goes wrong.
• Planned window — start and end, read in the viewer’s own timezone.
• Governance status — draft, in review, approved, rejected or freeze conflict.

Everything else stays where it already is. The summary, description, comments, attachments, links, sprint, components and workflow status remain Jira’s — searchable by JQL, visible on boards and dashboards, reportable, and governed by the project’s own permission scheme.

A lifecycle you cannot skip

Statuses move in one direction, and the rules are enforced server-side rather than by hiding a button:

• A normal or standard change must pass through review before it can be approved.
• An emergency change can be approved straight from draft — because the alternative is a process people route around at 3am and never come back to. The approval is still demanded; it is captured afterwards rather than waived.
• A change cannot be approved while an approver has rejected it, or while approvals are outstanding.
• A change cannot be approved while it sits inside a freeze window that has not been overridden.
• Approved and rejected are terminal. Reopening means a new decision, visibly.

Approvals that hold up

An approval names a person. Only that person can answer it, and only once. Three rules do the work, and all three are enforced in the resolver rather than in the interface:

• No self-approval. Refused outright, not flagged. It is the most common audit finding in change management and trivially avoidable; an app that permits it while claiming to produce audit evidence is selling something it does not deliver.
• Only the named approver may decide. An agent who could answer on somebody else’s behalf makes the record a fiction.
• A decision is final. Re-deciding would rewrite history the audit chain has already sealed. A changed mind is a new approval request, on the record.

Requesting an approval posts a comment on the issue, so your own Jira notification scheme tells the approver. The app sends no email of its own — it has no way to.

Freeze windows

A freeze window is a named period with a reason. Declaring one immediately re-checks every change already scheduled, because a freeze announced after the fact is the normal case — somebody calls a code freeze for the end of the quarter and everything already booked into it has to be looked at again.

• A change scheduled inside a window is flagged freeze conflict and cannot be approved.
• Only a project administrator can override, and the override needs a written reason. Both the override and the reason go on the audit trail.
• An override is bound to the window it was granted for. Move the change into a different freeze and the conflict is raised again — a permission to breach one freeze is not a standing exemption.

Change calendar

A month grid of what is scheduled, with freeze days shaded on the grid itself rather than listed underneath — a list is something you have to remember to cross-check; a shaded cell is not. Changes appear as chips on their day, and anything sitting inside a freeze is marked. Times render in each viewer’s own timezone, so a window that reads 02:00 in London does not read 02:00 to somebody in Sydney.

CAB workbench

The agenda is a view over your issues, approvals and freeze windows — there is no CAB table, no meeting object and no board membership, because authority here is per-approval and delegable. What it adds over a JQL filter is ordering with an opinion:

• Awaiting you first, whatever its risk — the agenda’s job is to tell one person what to do next.
• Freeze conflicts next, because they are blocked until a human acts.
• Then risk descending, then the soonest window, with unscheduled last so a blank start never reads as imminent.

Filters for high risk, emergency, in freeze and awaiting me each carry their own count over the unfiltered set.

Tamper-evident audit trail

Every governance action appends an entry to a per-project hash chain: what happened, when, and who did it. Each entry carries a SHA-256 hash over its own contents and the hash of the entry before it, starting from a genesis value derived from the project key.

Verification recomputes the whole chain from genesis and distinguishes three different failures:

• An altered entry — its contents no longer match its own hash.
• A re-pointed entry — it no longer follows the one before it, even if it rehashes cleanly on its own.
• A removed entry — there is a gap in the sequence.

Recording is not best-effort. The audit entry is written before the change it describes, so a failure leaves an entry describing something that did not happen rather than a change nobody recorded. If the entry cannot be written, the action fails.

Evidence export

Export the governance record for a whole project or a single change, in JSON (lossless, re-verifies offline) or CSV (opens in a spreadsheet). Every export carries a verification block computed at the moment you take it, stating how many entries were recomputed and whether every link held.

An export taken from a broken chain says so in its first lines, in the file as well as on the screen. It is never quietly downgraded to a warning.