Pattern Catalogue 2.0 Harmonisation

### Context
During the catalogue restructuring, several groups of patterns were identified that overlap significantly or are too narrowly scoped. The team agreed to merge these into broader, higher-level patterns and to broaden overly specific patterns rather than simply removing them.

Following the Patterns 2.0 launch, the team agreed to extend this work into a full catalogue quality review — auditing all existing patterns for overlap, duplication, staleness, and consistency against the current pattern template. Paula raised that teams she works with get overwhelmed when directed to the catalogue without a clear sense of what to prioritise, and that the reorganisation surfaced more consolidation opportunities beyond the initially identified set.

A full categorisation review has now been completed. The tables below capture all proposed changes to existing patterns, and the new patterns that should replace them where applicable.

---

### Existing patterns: proposed changes

#### Delete
| UID | Pattern | Reason |
|---|---|---|
| arch-9 | Use a service mesh only if needed | Too specific |

#### Remove or consolidate (potential duplicate)
| UID | Pattern | Reason |
|---|---|---|
| req-1 | Enable text compression | Already covered by a general "Compress data" pattern |

#### Rename
| UID | Pattern | Proposed new name |
|---|---|---|
| req-2 | Keep request counts low | Reduce unnecessary file loading in a HTML request |

#### Update content (outdated or needs improvement)
| UID | Pattern | Notes |
|---|---|---|
| arch-11 | Serve images in modern formats | Needs updating |
| dev-4 | Encrypt what is necessary | Needs updating and rephrasing |
| arch-10 | Match your service level objectives to business needs | Needs rephrasing to connect to requirements phase |
| ops-13 | Compress transmitted data | Update content |
| ops-14 | Reduce transmitted data | Update content |
| ops-10 | Time-shift Kubernetes cron jobs | Rewrite as a more general "time-shift cron jobs" pattern |

#### Replace with consolidated patterns
| UID | Existing pattern | Replaces with |
|---|---|---|
| dev-5 | Scale infrastructure with user load | Dynamic scaling based on demand |
| dev-7 | Scale Kubernetes workloads based on relevant demand metrics | Dynamic scaling based on demand |
| dev-10 | Evaluate other CPU architectures | Adopt energy-efficient processor architectures |
| dev-14 | Use cloud native processor VMs | Adopt energy-efficient processor architectures |
| dev-15 | Delete unused storage resources | Optimise storage utilization |
| ops-1 | Set storage retention policies | Optimise storage utilization |
| ops-2 | Optimize average CPU utilization | Optimize CPU utilization |
| ops-3 | Optimize peak CPU utilization | Optimize CPU utilization |
| ops-4 | Deprecate GIFs for animated content | Optimize image delivery |
| ops-5 | Match utilization requirements of virtual machines (VMs) | Right-size compute resources |
| ops-6 | Match utilization requirements with pre-configured servers | Right-size compute resources |
| ops-7 | Scale down applications when not in use | Scale down applications when not in use (generalised) |
| ops-8 | Scale down Kubernetes applications when not in use | Scale down applications when not in use (generalised) |

---

### New patterns to create

The following new patterns are proposed, either as consolidations of the above or as net-new additions identified during the categorisation review.

#### Consolidation patterns (replace existing)
| Pattern | Category | Description |
|---|---|---|
| Adopt energy-efficient processor architectures | Architecture | Merged from: Evaluate other CPU architectures + Use cloud native processor VMs |
| Minimize transmitted data size | Development | Merged from: Compress transmitted data + Reduce transmitted data |
| Optimize image delivery | Development | Merged from: Deprecate GIFs for animated content + Serve images in modern formats |
| Dynamic scaling based on demand | Operations | Merged from: Scale infrastructure with user load + Scale Kubernetes workloads based on relevant demand metrics |
| Scale down applications when not in use | Operations | Generalised from: Scale down applications when not in use + Scale down Kubernetes applications when not in use |
| Optimize CPU utilization | Operations | Merged from: Optimize average CPU utilization + Optimize peak CPU utilization |
| Optimise storage utilization | Operations | Merged from: Delete unused storage resources + Set storage retention policies |
| Right-size compute resources | Operations | Merged from: Match utilization requirements of VMs + Match utilization requirements with pre-configured servers |

#### Net-new patterns
| Pattern | Category | Description |
|---|---|---|
| AI Training Efficiency | Architecture (TBC) | 📌 Description to be defined |
| Inference Optimization | Architecture (TBC) | 📌 Description to be defined |
| Carbon-Aware AI Scheduling | Architecture (TBC) | 📌 Description to be defined |
| Choose a sustainable hosting provider | Architecture | Prioritize data centers using clean energy on-premises or via their utility, over those relying solely on renewable energy contracts |
| Monitoring and benchmarking | Architecture | Continuously monitor and benchmark environmental impact from the start; use results to manage impact across releases |
| Include the Planet in your Brief | Requirements | Set environmental and emission reduction goals linked to OKRs; connect to business and user opportunities |
| Remove non-essential features from scope | Requirements | Validate user needs, prioritise stories, define MVP, regularly review feature relevance |
| Prioritize Longevity & Maintainability | Architecture | Design for longevity using robust, well-documented, modular technologies |
| Prioritize a mobile-first approach | Design | Validate user journeys, develop mobile-specific content, remove non-essential features, optimize multimedia |

---

### What needs to happen
- [ ] Raise individual PRs for each proposed merge/consolidation in the tables above
- [ ] Each PR should show the original patterns and the proposed replacement
- [ ] At least one subject matter expert should review each merge to ensure no important guidance is lost (Liya's request)
- [ ] For overly specific patterns: attempt to broaden the wording first before proposing removal
- [ ] Team to review and approve PRs asynchronously
- [ ] Generate drafts for net-new patterns using the green software pattern skill
- [ ] Confirm category and description for the three AI patterns (AI Training Efficiency, Inference Optimization, Carbon-Aware AI Scheduling) — engage Green AI Committee
- [ ] Audit any remaining patterns not listed above for template consistency and content quality
- [ ] Document a lightweight ongoing process for pattern quality review

### Acceptance criteria
- All patterns in the change tables above have been actioned (deleted, renamed, updated, or replaced)
- All consolidation patterns have been drafted and reviewed by at least one SME before merging
- No patterns removed without an attempt to broaden them first
- All new patterns generated via the skill and reviewed through the standard workflow
- All three AI net-new patterns (Training Efficiency, Inference Optimization, Carbon-Aware AI Scheduling) have confirmed descriptions and categories
- Remaining patterns not listed above reviewed for template consistency
- A documented process exists for ongoing pattern quality review

### Dependencies
- Green software pattern skill (for generating new pattern drafts)
- Green AI Committee input on the three AI net-new patterns
- Reviewer capacity (Liya / Franzi)
- Backlog pattern proposals triage (#) — consolidation decisions should account for incoming generated patterns to avoid creating new overlaps