This checklist defines the governance rules for adding new phases or steps to the system without introducing structural drift, scope overlap, or navigation ambiguity.
It exists to ensure the execution order, responsibility boundaries, and internal routing remain stable and predictable as the system evolves.
Checklist Objective
Prevent structural drift by enforcing consistent rules for introducing new phases or steps into the system.
Scope Boundary
This checklist governs:
- Adding new top‑level phases
- Adding new steps within an existing phase
- Required updates to Start Here and landing pages
- Change control rules for structural modifications
This checklist does not govern:
- Editorial wording changes
- Formatting or design adjustments
- Minor clarifications that do not affect structure or order
Checklist Steps — Adding a New Phase
A phase represents a top‑level system with its own responsibility boundary.
- Confirm the phase represents a distinct system
- Confirm it cannot be owned by an existing phase
- Confirm it introduces a new responsibility boundary
- Confirm it will contain multiple internal steps or runbooks
When adding a new phase:
- Create a dedicated landing page for the phase
- Define purpose, scope boundary, and usage rules
- Define a clear “Start Here” entry point for the phase
- Add the phase to Start Here as a new H2 (linked)
- Place the phase in the correct execution order
Disallowed:
- Phases created for organization only
- Phases with a single checklist
- Phases that overlap existing scope
Checklist Steps — Adding a New Step
A step is an atomic checklist or runbook executed within a phase.
- Confirm the step has a single responsibility
- Confirm it produces a verifiable output
- Confirm it can be executed independently
- Confirm it fits within an existing phase’s scope
When adding a new step:
- Add it to the phase landing page sequence
- Add it to the Start Here list under the correct phase
- Place it in a specific, intentional order
- Define Pause & Lock if it establishes a baseline
Disallowed:
- Multi‑purpose steps
- Implicit or undocumented dependencies
- Optional steps without explicit labeling
Checklist Steps — Start Here Updates
Start Here is the global execution index and must always reflect the current system state.
- Every phase listed must have a landing page
- Every step listed must exist and be linked
- No phase or step may exist outside Start Here
- All steps must be visible (no partial lists)
Any structural change requires Start Here to be updated in the same change set.
Checklist Steps — Landing Page Updates
- Landing page sequences must reflect actual execution order
- Steps listed must match Start Here exactly
- No cross‑phase routing is allowed
- Scope boundaries must remain accurate
Drift Detection Rules
Structural drift is defined as:
- A step exists but is not listed in Start Here
- A phase exists without a landing page
- A landing page lists steps not shown in Start Here
- Overlapping responsibility between phases
Any detected drift requires review before publishing changes. Silent fixes are not allowed.
Required Output
- New phases or steps correctly placed
- Start Here fully updated
- Landing pages synchronized
- No scope overlap or ordering ambiguity
Pause & Lock
Once approved, phase order and step order are treated as locked. Changes require documented justification and deliberate review.