![[✍blog/blog-assets/drawio/platform-change-governance-process.svg]] ## Decision Phase Every change starts as a **Problem Statement** (what's broken/needed, and why). It then hits a decision fork — does this need a new architectural decision? - **Flow 1 (yes)** → write an **ADR** (Architecture Decision Record) first. - **Flow 2 (fast-track, "no")** → skip the ADR entirely and go straight to the spec. ## Design Phase Both flows converge at the **Implementation Spec** (the technical "how"), which references the ADR when Flow 1 was taken. ## Delivery Phase - Gate: **Definition of Ready** — if not ready, loops back to refine the Implementation Spec. - Once ready, work moves through the **SDLC** (Design → Build → Test → Deploy), tracked as Jira stories with code review + test evidence attached. - Gate: **Definition of Done** — if not done, loops back into the SDLC rather than escaping incomplete. ## Operations Phase Once done, the change produces: - **As-Built (SOP)** — what was actually deployed. - **How-To (SOP)** — how operators run/use it. An optional dashed feedback loop runs from How-To back to the original Problem Statement — lessons learned can spawn the next change. ## Threading A single **Jira Epic (LH-XXX)** runs through every artifact (dotted line on the right of the diagram), so the Problem Statement, ADR, Spec, SDLC stories, and SOPs are all traceable back to one change ID. Color coding marks the four phases (blue/purple/green/amber); the amber dashed path is the fast-track bypass and the red dashed paths are the gate-failure retry loops.