Reference

Terminology

Term	Meaning
Run	One execution of one planned change, attached to one Jira issue.
Runbook	The ordered execution steps for that run.
Preflight	What must be true before the window opens.
Current step	The single step the run is on right now.
Success criteria	How the change is proved to have worked. Separate from the steps.
Verification	The stage where criteria are proved, after the work is done.
Deviation	A recorded departure from the plan, appended rather than edited in.
Rollback	The trigger and ordered procedure for undoing the change.
Run record	The immutable account of a finished run.
Run template	A saved procedure, applied to later runs as a snapshot.

The state machine

DRAFT → READY → ACTIVE → { VERIFYING | ROLLING_BACK } → { VERIFIED | ROLLED_BACK | FAILED }

State	Meaning	Plan
`DRAFT`	Being written.	Mutable working copy
`READY`	Finished and waiting for the window.	Frozen
`ACTIVE`	The window is open; the runbook is being worked.	Frozen
`VERIFYING`	Work done; criteria being proved.	Frozen
`ROLLING_BACK`	The rollback procedure is being worked.	Frozen
`VERIFIED`	Terminal. Every required criterion passed.	Immutable
`ROLLED_BACK`	Terminal. The change was undone.	Immutable
`FAILED`	Terminal. Ended without success and without rollback.	Immutable

There is no separate "closed" state. The three terminal states are closed, and a finished run does not become editable again.

Step and criterion states

A runbook step is waiting, active, complete, skipped or deviated. A success criterion is pending, passed or failed.

Steps against criteria

Deliberately two different things, and conflating them is the mistake the separation exists to prevent.

Execution steps are what the engineer does. Ordered, worked one at a time.

Success criteria are how the engineer proves the change worked. Checked after the work, during verification.

Finishing every step does not close a run successfully. The run moves to VERIFYING and becomes VERIFIED only once all required criteria have passed. A runbook that completed while the change did not work is an outcome the model can express, which is the reason for the split.

Rollback

A run's rollback holds a trigger, an ordered procedure, and optionally an expected recovery time. All three are written during preparation, not during the window.

Rollback readiness stays visible throughout an active run. Initiating rollback requires explicit confirmation and moves the run into a focused ROLLING_BACK state.

Deviations

Append-only. Recording one never alters the planned sequence, so the record shows the plan and the reality side by side.

Each deviation records the step it relates to, a timestamp, who recorded it, what happened, what action was taken, and optionally the impact and any evidence.

The run record

On reaching a terminal state a run becomes a read-only operational record covering the Jira issue, title and owner, the planned window against the actual start and end, the duration, the outcome, preflight completion, the planned steps against the actual timeline, every deviation, verification results, whether rollback was used, participants, and any notes or evidence.

It is immutable through normal operation. The single exception is redaction of sensitive data that should not have been entered, which is audited and never silent.

Who can see a template

A template is usable by anyone who can see the Jira change it was saved from. It is not scoped to a project, a team or a space.

A template carries real plan text (step titles, success criteria, rollback triggers) out of the run it was saved from and into the run it is applied to, where the person reads it. So the question asked when a template is listed or applied is the one that actually matters: could this person have read the change this procedure was written for? If they could, they may reuse it. If they could not, the template is not offered to them and not applied for them, and they are told it was not found, the same answer a template that does not exist gets, because a template's name can disclose a change on its own.

Two consequences worth stating plainly, because they are what a user notices:

One person working across several projects can reuse their own procedures freely. This app does not add barriers that Jira's own permissions do not already impose. A project wall would stop normal cross-project work on a change-management tool, and would still not answer the question above.
A template always belongs to the person who saved it, even if the change it came from is later deleted. They could read that change when they wrote the procedure, so nothing reaches them that did not already pass through their hands, and an operator does not lose their own work to someone else's housekeeping.

If Jira cannot be reached to answer the question, templates are not quietly hidden: the list says so and offers a retry.

Permission scopes

Scope	Why it is needed
`read:jira-work`	Reading the change being executed, and checking that a viewer can see that change before showing them anything derived from it. This is the app's authorization boundary, not a convenience.
`read:jira-user`	Showing who did what as a name rather than an opaque account id.
`storage:app`	The run ledger itself. Nothing the app stores exists outside it.
`report:personal-data`	Telling Atlassian which account ids the app holds, so account closures and updates come back and can be acted on.

There is no write scope. Runphase never creates, edits, transitions or comments on a Jira issue. A change executed through it leaves the underlying issue untouched.

Where data lives

In Forge app storage, scoped to your installation, on Atlassian infrastructure. The manifest declares no remotes and no external permissions, so the app cannot make a network request outside Atlassian: no analytics, no telemetry, no error reporting, no third-party processor, and no vendor-side copy. Atlassian reports every deployment as eligible for Runs on Atlassian.

Full detail is in the privacy policy.

The scope boundary

Runphase records execution. It does not perform it, and it does not govern it. Two rules decide every integration question, including ones not yet imagined:

Inbound evidence, yes. Outbound execution, no. Anything reporting into a run (a pipeline saying "step 3 finished, here is the output", or a check whose result verifies a criterion) is on-thesis. It needs no credentials to customer infrastructure and keeps the app inside Atlassian. Anything reaching out to run a change would put Runphase in the credential-holding business and forfeit Runs on Atlassian.
Jira owns the change. Runphase owns the window. Approvals, risk scoring, CAB, freeze periods and who signed off happen before the window and belong to Jira. What happens between "start" and "closed" belongs here.

Not in the product

Excluded by rule 1: firewall vendor APIs, automated network configuration, production automation, and Ansible or Terraform execution. Note that Ansible or Terraform reporting results into a run is allowed. It is the direction that matters, not the tool.

Excluded by rule 2: CAB replacement, complex approval workflows, automated risk scoring, change conflict detection, enterprise calendar orchestration.

Excluded as separate products: CMDB, incident management, monitoring, and ServiceNow, Slack, Datadog or GitHub integrations.