Patterns Analysis ‐ August 2026 ‐ Operations

I read all 18 patterns filed under Operations (capacity-management, resource-lifecycle, plus 4 top-level files), including three I'd already opened earlier in this thread (optimize-peak-cpu-utilization, use-circuit-breaker, carbon-aware-ai-scheduling). This is, by a wide margin, the most duplication-riddled category found in this entire review — several pairs are near-verbatim copies of each other. I'm leading with that finding since it matters more here than in any prior category.

The duplication picture (read this first)

Cluster	Patterns	Evidence
VM rightsizing (near-identical)	match-utilization-requirements-of-vm ↔ match-utilization-requirements-with-pre-configured-server	Same author (dubrie), same date, verbatim-identical Description, SCI Impact, Assumptions, and Considerations text. Only the Solution sentence differs (elastic resize vs. picking a different fixed SKU).
CPU utilization (near-identical)	optimize-avg-cpu-utilization ↔ optimize-peak-cpu-utilization	Same author, same date, verbatim-identical opening Description paragraph. Differ only in targeting average vs. peak. optimize-peak-cpu-utilization is also already flagged (Requirements review) as overlapping with shed-lower-priority-traffic and queue-non-urgent-requests.
Storage cleanup (near-identical)	delete-unused-storage-resources ↔ set-retention-policy-on-storage-resources	Same author (greenhsu123), same date, word-for-word identical Assumptions text ("If we choose not to delete all storage resources because they might be needed in the future..."). Differ only in manual vs. automated deletion.
Storage rightsizing (mirrors VM cluster)	optimise-storage-resource-utilisation	Same author as the storage-cleanup pair; its Assumption text mirrors match-utilization-requirements-of-vm's almost word-for-word, substituting "storage" for "VM."
Scale-to-zero (general vs. K8s-specific)	scale-down-kubernetes-workloads ↔ scale-down-unused-applications	The general pattern's own Considerations names Kubernetes as an example mechanism — the two are the same idea at two altitudes.
Broader scale-down umbrella	scale-infrastructure-with-user-load, remove-unused-assets	Both restate "find underutilized/unused resources and cut them" — overlapping with several patterns above from a slightly different angle.
Carbon-intensity time-shifting (partial overlap)	time-shift-kubernetes-cron-jobs ↔ carbon-aware-ai-scheduling	Both shift execution to low-carbon-intensity windows; the AI pattern is broader (also covers spatial/region shifting) while the cron-job pattern is narrower and non-AI. Worth a cross-reference at minimum.

13 of the 18 patterns in this category (72%) carry a duplication finding. This looks like the result of multiple contributors (dubrie, greenhsu123, yelghali) independently writing near-identical "match capacity to actual demand" patterns across VM/storage/Kubernetes/app framings in the original 2022 seeding round, without checking existing coverage. This is the single most important finding for this category — before doing per-pattern line-edits, I'd strongly recommend a consolidation pass merging each near-identical pair into one pattern (e.g., one "Rightsize compute to match utilization" pattern covering both elastic resize and pre-configured-SKU selection as named techniques; one "Delete or auto-expire unused storage" pattern covering manual and policy-driven deletion).

Summary matrix

#	Pattern	Passes	Fails	Note
1	match-utilization-requirements-of-vm	7	5,8,10,11	Consolidate with #2
2	match-utilization-requirements-with-pre-configured-server	7	5,8,10,11	Consolidate with #1
3	optimize-avg-cpu-utilization	8	5,10,11	Consolidate with #4
4	optimize-peak-cpu-utilization	8	5,10,11	Consolidate with #3
5	scale-down-kubernetes-workloads	8	5,10,11	Consolidate with #6
6	scale-down-unused-applications	7	5,9,10,11	Consolidate with #5
7	scale-infrastructure-with-user-load	6	5,8,9,10,11	Consolidate into cluster
8	scale-kubernetes-workloads-based-on-events	8	2,5,10	Revision
9	use-circuit-breaker	9	5,10	Near-ready
10	carbon-aware-ai-scheduling	9	6,11(soft)	Near-ready
11	delete-unused-storage-resources	7	5,8,10,11	Consolidate with #14
12	optimise-storage-resource-utilisation	7	5,8,10,11	Consolidate into VM-rightsizing cluster
13	remove-unused-assets	6	5,8,9,10,11	Consolidate into storage-cleanup cluster
14	set-retention-policy-on-storage-resources	7	5,8,10,11	Consolidate with #11
15	scan-for-vulnerabilities	7	5,7,8,10	Revision
16	time-shift-kubernetes-cron-jobs	8	5,10,11(soft)	Minor revision
17	use-cloud-native-network-security-tools-and-controls	6	5,7,8,9,10	Revision
18	use-ddos-protection	6	2,5,8,9,10	Revision

---

Notable findings beyond duplication

Best pattern in the category: carbon-aware-ai-scheduling (9/11) — full Cost Impact, honest "regional cost arbitrage may offset environmental gains" trade-off, extensive real Considerations. Only fails Principle 6 (9 Solution bullets + 8 Considerations is the longest of any pattern reviewed in this whole exercise — many bullets restate the same idea) and a soft Principle 11 overlap with the narrower time-shift-kubernetes-cron-jobs.

use-circuit-breaker (9/11) — clean, honest, well-scoped. Only fails on the now-familiar missing-Cost-Impact gap (5,10) — doesn't mention the real operational cost of tuning circuit-breaker thresholds (a well-known source of false-positive trips).

Clear Principle 2 (Patterns, not Practices) violations:

• use-ddos-protection: Solution names four specific commercial products as the entire prescription — "AWS Shield, Azure DDoS Protection, GCP DDoS Protection, CloudFlare." This isn't illustrative example-naming, it is the solution.
• scale-kubernetes-workloads-based-on-events: Solution prescribes "use KEDA" directly, a specific named tool rather than a generic "use an event-driven autoscaler" framing (milder than the DDoS case since KEDA is the closest thing to a CNCF standard for this problem, but still a named-product prescription).

Two Assumptions that are actually mislabeled Cost content:

• use-ddos-protection's sole Assumption is "There is budget for the DDoS protection service" — this is cost information wearing an Assumptions costume, and it's also the only content anywhere in the pattern that even gestures at Cost Impact, which is otherwise entirely missing.

A genuinely serious, under-addressed risk: both storage-cleanup patterns (delete-unused-storage-resources, set-retention-policy-on-storage-resources) involve permanently destroying data, and only one of the two even mentions the risk ("we may lose access to data that might be needed in the future") — the automated-retention-policy version, which is arguably the more dangerous of the two (silent, automated, harder to catch before damage is done), doesn't mention this risk at all. Whichever pattern survives a consolidation pass should carry this warning prominently, ideally with a recommendation for a review/approval step or soft-delete/grace-period before permanent deletion.

Missing Cost Impact is nearly total in this category: 17 of 18 patterns lack it — every legacy (2022–2024) pattern in Operations, with carbon-aware-ai-scheduling (the one modern AI-focused submission) being the sole exception. This matches the pattern seen in every category reviewed so far: pre-2024 submissions systematically predate Cost Impact enforcement.

To publish, requires (category-level, not per-pattern):

1. Resolve the five duplication clusters via a team consolidation decision before any further line-editing — merging near-identical pairs (VM rightsizing, storage cleanup) is close to a copy-paste job; the looser clusters (scale-down general vs. K8s, storage rightsizing vs. VM rightsizing) need slightly more editorial judgment but should still merge.
2. Add Cost Impact to every surviving pattern post-consolidation.
3. Move the "budget for DDoS protection" content out of Assumptions and into a real Cost Impact section once use-ddos-protection is revised.
4. Add the data-loss risk warning to whichever storage-cleanup pattern survives consolidation, emphasizing it more heavily for the automated/retention-policy variant.
5. Replace narrative "Suppose we choose an oversized VM..." style Assumptions (a recurring format across nearly every dubrie/greenhsu123 pattern in this category) with direct, testable statements.

Recommendation: This category needs a consolidation pass first, ahead of the usual per-pattern revision work applied to the other categories — doing detailed line-edits on 13 patterns that are largely destined to be merged or retired would be wasted effort.