Standard lifecycle
The reference architecture is a maintained standard. It is not a permanent list of product choices.
Review schedule
Section titled “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
Section titled “Review process”-
Check current support.
Review the primary Cloudflare, Astro, GitHub, and package documentation.
-
Check live use.
Compare the standard with active repositories and Cloudflare projects.
-
Review evidence.
Use incidents, performance, cost, and developer work as inputs.
-
Propose a change.
Explain the benefit, migration effect, risk, and recovery plan.
-
Test the change.
Use a reference project or a bounded pilot.
-
Publish the decision.
Update the canonical standard and this reference site in one pull request.
Change classes
Section titled “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
Section titled “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.