The governance lifecycle

Who this is for: agents.

A change record has exactly five statuses. This guide is the map.

The five statuses

Rejected is the end. Nothing moves out of it and there is no reopen; a change that needs revisiting after it was rejected is a new change record.

Approved is the end for you, but not for the system. No button takes a change out of Approved. One thing does: moving the planned dates outside the window the change was approved for withdraws the approval and sends it back to In review (guide 3). An approval is permission to make that change at that time, not a permanent clearance.

Concessa has no “implemented” or “closed” status: it governs the decision, and the Jira issue carries on through your own workflow afterwards.

The map

Solid arrows are moves you make; dashed arrows are moves the system makes for you.

Approved and Rejected have no way out. Freeze conflict is never something you set — only something the system does to you, and only two things clear it.

What you can move, and when

The buttons under Change record status, at the bottom of the panel, show only the moves that are legal now. They move the change record; the Approve and Reject on an approver’s own row answer that person’s approval request, which is a different thing — see Approvals.

What has to be true before a change can be approved

Four checks, in this order. The first that fails is the message you get.

1. The move must be legal from where the change is now.
2. Every approver must have approved — unless the change type is Emergency.
3. Nobody must have rejected. This applies to emergency changes too.
4. The change must not be sitting in an unoverridden freeze window. This applies to emergency changes too.

So an emergency change may be approved with no approvals at all, but never over a rejection and never through a freeze that nobody has overridden.

Moves the system makes for you

Five status changes happen without anybody pressing a button. All five are audited like any other.

That last one catches people out: rescheduling out of a freeze returns the change to Draft, not to whatever status it held before the conflict. Send it for review again.

After approval: the outcome

The five statuses above answer one question — who authorised this, and when — and stop there. They still do. Concessa separately lets you record what happened: whether the change was carried out, whether it worked, and — for the changes that most need it — a short post-implementation review. This is a fact recorded about the change, not a sixth status. “Approved” still means exactly what it always has; there is still no “implemented” or “closed” status, and the diagram above is complete on its own terms.

Recording it

The panel’s Outcome section says what it is waiting for:

• Before approval, it says the outcome is recorded once the change is approved and carried out. Once the planned start has passed — or if the change has no planned start — it also offers Record that this change was carried out without approval (below).
• Once approved, it offers Record the outcome. If the approved window has ended and nothing has been recorded, a No outcome recorded warning names the date and gives the two routes: record what happened, even if the change did not go ahead; or, if it was postponed, move the planned dates to a new start in the future, which asks the approvers again.

The form asks What happened? — Implemented, Backed out, Fixed forward, Failed, or Not carried out, with the chosen answer explained under the field — then the actual start and end, in your time zone, and whether the change caused an incident that you know of. Nothing is filled in for you: copying the approved window into the actual times would make “inside the window” the answer you get by not looking. Choosing Not carried out removes the questions after it; choose again and what you typed is still there. Save the outcome records it.

Afterwards the section shows the outcome, how the actual window compares with the approved one, whether an incident was caused, and whether a post-implementation review is required or optional. It offers Revise the outcome — a corrected answer and a reason, and at least one answer must change — and Start the post-implementation review, or Correct the post-implementation review once one is saved. A review’s lesson is up to 1,000 characters, a reason up to 500, and both are recorded permanently in the audit trail. Revising the outcome clears a saved review; it stays in the audit trail and can be written again.

Once an outcome is recorded:

• The change’s details are locked. Edit change details is no longer offered; the panel says the details are locked because the outcome has been recorded. If the outcome itself is wrong, revise it; for anything else, add a Jira comment.
• Approvals stay open, and keep working normally — a decision is still recorded, but it no longer moves the change’s status. What happened has happened.
• No system move touches the record any more — a freeze declared afterwards is still shown on the panel, but never changes a locked record’s status.

Once an approved change’s window has passed with no outcome recorded yet, its dates can only move to a future start — a genuine postponement. Moving them to match what actually happened is refused; record the outcome instead of rewriting the plan.

A change can also be declared carried out without ever having been approved, with Record that this change was carried out without approval. The form cannot record Not carried out — a change that was neither approved nor carried out has no outcome — and Save the outcome asks you to confirm in words first: the change is counted in the evidence export as carried out without approval, it can no longer be approved, and a post-implementation review becomes required. For an emergency change, approve it instead; emergency changes may be approved after the event. Declaring it is deliberately allowed: refusing it would make the one case an auditor most needs to see invisible instead.

None of this is covered by the buttons table above, on purpose: recording an outcome is not a status move, so it earns its own space rather than a new row in that table. Guide 8 covers how it feeds the evidence export.

What this guide does not cover

Freeze windows and overrides in detail (guide 5), and the approval rules themselves (guide 3).