Everything it does, in detail

The change record

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

• Summary of the change — what is changing, and why, in a sentence or two. Required, and the one field that says what the change actually is.
• Risk — low, medium or high.
• Change type — normal (assessed and approved before it is scheduled) or emergency (restores service now; approval is captured alongside, not before). There is deliberately no “standard” type: a pre-authorisation you grant yourself on the form is not one.
• 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 issue’s own summary and description, its 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. The summary of the change is the one deliberate exception: a Jira summary can be edited afterwards without trace, so what the change was said to be at the moment it was approved has to live in the chain instead.

A lifecycle you cannot skip

Statuses move by rule rather than by permission, and the rules are enforced server-side rather than by hiding a button:

• A normal 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.
• Rejected is terminal. Revisiting a refused change means a new change record, visibly.
• An approval covers the dates it was given for. Move an approved change’s planned window outside that window and the approval is withdrawn automatically: the change returns to review, its approvers are asked again, the withdrawal is written to the chain and Concessa comments on the issue. Shortening inside what was approved changes nothing. No person can take a change out of approved; this is the only thing that does.

Approvals that hold up

An approval names a person. Only that person can answer it, and only once. Four rules do the work, and all four 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.
• Nor may the person who recorded it. The approver is neither the person asking nor the author, and those differ whenever one agent writes a change up and another sends it for approval. Without this, a colleague can route the request back to the author and the record shows two names for one person’s decision.
• 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 — and so is the system asking again after a change’s dates move outside the window it was approved for. The original decision stays sealed either way.

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; move it clear of every freeze and the override retires, because there is no breach left to excuse. Rescheduling within the same window keeps it — that is still the freeze being breached.

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. 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.

Each change is a block coloured by its risk, running across every day of its planned window rather than sitting on the day it starts — a four-day migration should look like four days. Every block names its risk and its status in words, so the colour is the quick read and the grid still works in greyscale and for a colourblind reader. A change holds the same row all week, so a long one reads as a bar and not a staircase; days are a fixed height, so the dates stay put as changes come and go; and a day with more than fits says how many it is hiding. Anything inside an unoverridden freeze is marked with a warning that leads the block, where a truncated column cannot cut it off.

CAB workbench

Two halves. Above, the board’s meetings — when it met, who was there, what it discussed and what it decided to do. Below, the change agenda: a view over your issues, approvals and freeze windows, ordered with an opinion.

A meeting is a record, not a gate. It is never a precondition for approving a change and no meeting outcome moves a change’s status — authority stays per-approval and delegable, exercised on the change itself. What a meeting adds is somewhere for the board’s own business to be a record too, rather than living in a diary and a chat thread.

Meetings

• Created from a cadence, not typed in — weekly, fortnightly or a weekday of the month, with a duration and a timezone — up to a rolling horizon, and never in the past.
• Attendance is anybody the project can assign work to, not only people who use Concessa, each marked invited, attended or apologies.
• Every meeting starts from a standing agenda an administrator sets, then diverges: editing this meeting’s items never touches the template that produced it.
• Marking one held seals it. Agenda, attendees, attendance marks and attached changes all freeze, and each attached change gets a comment saying it was reviewed here. A comment Jira refuses can be retried; the meeting is held either way, because it happened whether or not the courtesy copy landed.
• Cancelling takes a reason and posts nothing — those changes were not reviewed, so they come back as suggestions next time. “Not held” and “nobody came” are different facts, and the record says which.
• Neither a held nor a cancelled meeting reopens, and nothing in the product deletes one.

Actions

What a meeting decided to do, owned by somebody who was at it: a description, an owner drawn from that meeting’s attendees, an optional due date and an optional change. Actions are the one part of a held meeting that stays editable, because the work usually outlives the meeting that raised it. The workbench lists every open action across every meeting, soonest due first, and an overdue one says Overdue in words rather than only in red.

The change agenda

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, and a line under the table names the filter you are on in words, so one you set and forgot cannot quietly hide rows.

Change keys open the issue in a new tab, so working down an agenda never costs you the filter you were on.

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.

The chain is per project, and so is its numbering. The audit trail in an issue panel shows one change’s own entries out of that sequence, which is why its numbers skip: the gaps are other changes, not missing links. The export is the whole chain, and the only place the two can be told apart.

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.