---
title: "Standard lifecycle"
description: "Review the reference architecture on a fixed schedule and after material Cloudflare or software delivery changes."
url: "https://architecture.mnppi.org/governance/lifecycle/"
status: "Current"
last_updated: "2026-07-23"
---

# Standard lifecycle

**Standard details**

- Status: Current
- Reviewed: July 23, 2026
- Cadence: Review each quarter

The reference architecture is a maintained standard.
It is not a permanent list of product choices.

## Review schedule

Review the standard:

- Each quarter.
- After a material Cloudflare product change.
- After a security incident.
- After a failed recovery exercise.
- Before a high-risk project adopts a new platform feature.
- When a supported framework reaches the end of its support period.

## Review process

1. **Check current support.**

   Review the primary Cloudflare, Astro, GitHub, and package documentation.

2. **Check live use.**

   Compare the standard with active repositories and Cloudflare projects.

3. **Review evidence.**

   Use incidents, performance, cost, and developer work as inputs.

4. **Propose a change.**

   Explain the benefit, migration effect, risk, and recovery plan.

5. **Test the change.**

   Use a reference project or a bounded pilot.

6. **Publish the decision.**

   Update the canonical standard and this reference site in one pull request.

## Change classes

| Class              | Example                             | Required action                                  |
| ------------------ | ----------------------------------- | ------------------------------------------------ |
| Editorial          | Clearer wording or links            | Review and publish through normal checks.        |
| Compatible control | A new validation check              | Test the check and update adoption guidance.     |
| Stack change       | A new default service or framework  | Complete a reference pilot.                      |
| Breaking control   | A rule that blocks current projects | Add migration, exception, and recovery guidance. |
| Retirement         | Removal of a default tool           | Define the supported replacement and transition. |

## Version approach

The site presents one current standard.
Git history provides the detailed change record.

Create formal versions only when multiple supported baselines become necessary.
Do not add version menus before that need exists.