Patterns Analysis ‐ August 2026 ‐ Requirements

Cross-category summary

Pattern	Passes	Fails	Recommendation
Encrypt what is necessary	7	4 (4,5,8,10)	Revision
Match SLO to business needs	7	4 (5,8,9,10)	Revision
Optimize impact on customer equipment	4	7 (3,4,5,7,8,9,10)	Revision (substantial)
Shed lower priority traffic	6	5 (3,5,9,10,11)	Consolidation

Systemic issues across the whole Requirements category:

Every single pattern is missing Cost Impact. This isn't an isolated oversight — it's a category-wide gap. Worth flagging to whoever maintains the template/review checklist, since it suggests older submissions (all four are 2022–2023 vintage) predate stricter enforcement of Principle 10.
Two of four patterns (Encrypt, Match SLO) have Assumptions sections that are narrative/vague rather than testable — a recurring pattern-authoring habit worth calling out generally, not just per-pattern.
Two of four patterns (Optimize customer equipment, Shed traffic) have drifted into Development/Operations-style engineering language despite being filed under Requirements — this is the specific anti-pattern the skill's own guidance calls out by name, and it affects half this category.
Shed lower priority traffic has a real duplication problem with two patterns filed elsewhere in the catalogue — this is worth resolving before spending further editing effort on it in isolation.

I read all four patterns in the Requirements category and cross-checked the wider catalogue for duplication candidates. Findings below, pattern by pattern, then a cross-category summary.

1. Pattern Assessment: "Encrypt what is necessary"

Overall Assessment: Needs Revision

1. Fewer, Better, Broader — ✓ PASS. Coherent single theme (selective encryption by data sensitivity), reasonably substantive (3-point Solution, 3-point Considerations, 1 reference).

2. Patterns, Not Practices — ✓ PASS. Solution ("carefully consider sensitivity," "revise policy," "choose the appropriate algorithm... based on needs") stays directional — no specific cipher/library named.

3. Honour the Submitter's Framing — ✓ PASS. Framed as a policy/classification decision, consistent with its Requirements-category placement.

4. Action on Resource Format — ✗ FAIL. Title is "Encrypt what is necessary" — the resource is "what is necessary," a circular qualifier rather than a named resource (compare to the good example "Cache static data," where the resource is explicit). Better: "Encrypt only sensitive data."

5. Complete Required Sections — ✗ FAIL. No Cost Impact section. Also an internal inconsistency: the Description explicitly states encryption "inflates the size of the data being stored... especially noticeable for smaller files" (an M-type claim), but the SCI Impact section only lists E — the storage/embodied claim made in prose never makes it into the SCI Impact bullets.

6. Conciseness Matters — ✓ PASS. Three tight Solution bullets, not padded.

7. Decision Confidence — ✓ PASS. Broadly applicable (any team storing both sensitive and non-sensitive data can act on this), and Considerations flags "hard to implement post application design" as a real gating factor.

8. Specific, Testable Assumptions — ✗ FAIL. Evidence: "There is an assumption that a significant amount of data is not sensitive and can be stored unencrypted." "Significant amount" is unquantified — no testable threshold, same hedge-word problem as the framework's own bad example ("if needed").

9. Real Complications in Considerations — ✓ PASS (weak). Two of three bullets just restate the Solution (segregate data, separate storage), but "Hard to implement post application design" is a genuine, real friction point.

10. Complete Trade-off Visibility — ✗ FAIL. No Cost Impact section, despite real trade-offs here: cost of building/maintaining a data classification system, compliance/audit risk of under-classifying, versus CPU savings from selective encryption.

11. No Significant Duplication — ✓ PASS (with a note). evaluate-whether-to-use-TLS-termination.md covers the same "right-size your security overhead" instinct and even uses near-identical assumption phrasing ("does not have compliance requirements"), but targets a different resource (TLS connection point vs. data-at-rest/processing scope) — distinct enough to keep separate.

Passes on: 1, 2, 3, 6, 7, 9, 11 Fails on: 4, 5, 8, 10

To publish, requires:

Add a Cost Impact section (compute/CPU savings from selective encryption vs. cost of building a classification framework and compliance/audit risk of misclassification).
Reconcile the SCI Impact section with the Description's storage claim — add an M bullet or remove the storage claim from Description.
Replace "a significant amount of data" with a testable criterion, e.g., "Your data store contains a mix of regulated/PII data and operational metadata that carries no confidentiality requirement."
Retitle to name a concrete resource, e.g., "Encrypt only sensitive data."

Recommendation: Revision — solid foundation, contained fixes needed.

2. Pattern Assessment: "Match your service level objectives to business needs"

Overall Assessment: Needs Revision

1. Fewer, Better, Broader — ✓ PASS. Coherent, single decision (calibrate SLO to actual business need), well-referenced (5 links).

2. Patterns, Not Practices — ✓ PASS. "Adjust your solution design to the service level your actual end users require" stays at the decision level, no implementation prescribed.

3. Honour the Submitter's Framing — ✓ PASS. Squarely a requirements-definition question (what SLO target to set), matches category placement well.

4. Action on Resource Format — ✓ PASS (minor style note). Action/resource are clear enough ("Match" / "SLOs to business needs"), though it's a full possessive sentence ("your... your...") rather than the crisper imperative form used in other good examples ("Define performance budgets at requirements stage"). Not a blocking issue.

5. Complete Required Sections — ✗ FAIL. No Cost Impact section — and ironically, cost content exists but is misplaced: "This can reduce overall cloud cost because you will use less resources" sits under Considerations (line 43) instead of its own Cost Impact section.

6. Conciseness Matters — ✓ PASS.

7. Decision Confidence — ✓ PASS. The Assumptions narrative clearly names the mechanism (teams over-provisioning for SLOs, hot-standby duplication) and gives a clear directive: validate the business reason for the SLO target before designing to it.

8. Specific, Testable Assumptions — ✗ FAIL. Evidence: the entire Assumptions section (lines 37–39) is narrative rationale about typical engineering behavior, not a stated, checkable prerequisite. There's no concrete "this applies if X" statement — e.g., "Your service currently targets 99.99%+ uptime without a documented business/contractual justification."

9. Real Complications in Considerations — ✗ FAIL. Only two bullets; one ("can reduce overall cloud cost") is misplaced cost content, not a complication. The remaining one ("can impact end user experience negatively") is real but generic — no mention of SLA contract penalty exposure, multi-tenant customers with differing needs, or how to actually validate "business need" with stakeholders.

10. Complete Trade-off Visibility — ✗ FAIL. No dedicated Cost Impact section, despite partial cost content existing in the wrong place.

11. No Significant Duplication — ✓ PASS. No other pattern addresses SLO-to-business-need calibration specifically.

Passes on: 1, 2, 3, 4, 6, 7, 11 Fails on: 5, 8, 9, 10

To publish, requires:

Add a Cost Impact section; move the misplaced cost line out of Considerations into it, and expand (e.g., SLA renegotiation cost, potential revenue impact of increased downtime).
Rewrite Assumptions as a testable condition, e.g., "Your service currently maintains redundant/hot-standby infrastructure not justified by a documented SLA or business-continuity requirement."
Expand Considerations with real friction: contractual SLA penalty exposure, differing needs across customer segments, and how to validate "business need" concretely.

Recommendation: Revision.

3. Pattern Assessment: "Optimize impact on customer devices and equipment"

Overall Assessment: Not Suitable in current form — Needs Revision (major)

1. Fewer, Better, Broader — ✓ PASS. Coherent theme (extend customer device lifetime), three concrete example techniques.

2. Patterns, Not Practices — ✓ PASS. Examples ("implement new features using backwards-compatible code," "support older browser versions") stay at the approach level, not code-specific.

3. Honour the Submitter's Framing — ✗ FAIL. This is the exact failure mode the skill itself calls out: "Requirements patterns describe decisions made during project scoping... Neither category should default to engineering language... If you find a [Requirements] pattern's Solution reading like a developer task list, that is a signal to step back and reframe." The Solution here — "implement new features using code that is backwards compatible," "support older browser versions," "optimize network bandwidth" — reads exactly like a developer task list, not a requirements-stage scoping decision (e.g., "define a minimum supported device/OS tier as a project requirement" would be the Requirements-appropriate framing).

4. Action on Resource Format — ✗ FAIL. Title "Optimize impact on customer devices and equipment" — the resource is "impact," an abstraction, not a concrete resource. Close to the bad-example pattern "Reduce energy" (no specific resource named). Better: "Extend customer device lifespan" or "Design for backwards device compatibility."

5. Complete Required Sections — ✗ FAIL. No Cost Impact section. Considerations is a single cross-reference sentence ("Consider the other cloud patterns...") rather than substantive content.

6. Conciseness Matters — ✓ PASS.

7. Decision Confidence — ✗ FAIL. No concrete scope criteria (how far back should compatibility extend — one OS version, five years, a usage-share threshold?). Assumption is generic enough to apply to any initiative (see Principle 8).

8. Specific, Testable Assumptions — ✗ FAIL. Evidence: "This pattern assumes that the team does have sufficient time and resources to implement backwards compatibility and optimize the application." This is true of virtually every software initiative — it gives no pattern-specific, checkable criterion (e.g., "your analytics show a material share of users on devices/OS versions more than N years old").

9. Real Complications in Considerations — ✗ FAIL. Evidence: the sole Consideration is "Consider the other cloud patterns to optimize the application inside the cloud environment" — a cross-reference, not a complication. Real friction goes entirely unaddressed: larger QA/testing matrix, slower feature velocity, security-patching burden of supporting legacy OS/browsers, tension with dropping insecure legacy protocols.

10. Complete Trade-off Visibility — ✗ FAIL. No Cost Impact section, despite backwards compatibility carrying substantial, well-known costs (expanded test matrix, dev time for compatibility shims/polyfills) that go completely unmentioned anywhere in the pattern.

11. No Significant Duplication — ✓ PASS. No other pattern in the catalogue addresses customer-device-lifetime extension specifically.

Passes on: 1, 2, 6, 11 Fails on: 3, 4, 5, 7, 8, 9, 10 (7 of 11)

To publish, requires:

Reframe the Solution as a requirements-stage scoping decision, not a developer task list — e.g., "Define a minimum supported device/OS/browser tier as an explicit project requirement, informed by your user base's actual device age distribution," rather than "implement backwards-compatible code."
Retitle around a concrete resource: "Extend customer device lifespan" or similar.
Add a Cost Impact section covering expanded QA/test matrix cost and dev time for compatibility work, versus reduced customer hardware replacement (embodied carbon savings passed to the customer, not the provider — worth naming explicitly since this is an unusual "whose cost/whose benefit" split for this catalogue).
Replace the generic "sufficient time and resources" assumption with a testable one, e.g., "A material share of your user base is on devices/OS versions more than N years old" (check via analytics).
Rewrite Considerations to cover real friction: QA surface growth, security-patch burden on legacy support, conflict with deprecating insecure legacy protocols.

Recommendation: Revision (substantial) — this needs the deepest rework of the four; several fixes require re-approaching the pattern from the Requirements/scoping angle rather than patching sections in place.

4. Pattern Assessment: "Shed lower priority traffic"

Overall Assessment: Needs Revision, with a consolidation question to resolve first

1. Fewer, Better, Broader — ✓ PASS (flagged). Internally coherent, but see Principle 11 — this may be one of three overlapping "flatten peak demand" patterns rather than a fully distinct one.

2. Patterns, Not Practices — ✓ PASS. Stays at the energy/hardware-efficiency framing level, no specific shedding algorithm mandated.

3. Honour the Submitter's Framing — ✗ FAIL. Same issue as Pattern 3: this is filed as Requirements but reads as an Operations/engineering pattern throughout — "shedding lower priority traffic," "programmatically determine," "exponential shedding policy" is implementation guidance, not a requirements-stage scoping decision (e.g., "define acceptable service degradation tiers per traffic class as a business requirement" would fit Requirements).

4. Action on Resource Format — ✓ PASS. "Shed lower priority traffic" is a clean, concrete Action-on-Resource title, matching the style of the good examples well.

5. Complete Required Sections — ✗ FAIL. No Cost Impact section — consistent gap across all four patterns in this category.

6. Conciseness Matters — ✓ PASS.

7. Decision Confidence — ✓ PASS. The Assumption acts as a real gating condition (you need existing traffic prioritization to apply this), giving a practitioner without one a clear signal this doesn't yet apply to them.

8. Specific, Testable Assumptions — ✓ PASS. Evidence: "Your traffic must be prioritized and identified so that you can programmatically determine which can be shed and which is critical for system functionality." This is genuinely checkable — the best assumption statement in this batch of four.

9. Real Complications in Considerations — ✗ FAIL. The single Consideration ("have an exponential shedding policy... to reduce impact of high-variance spikes") is an implementation tip extending the Solution, not a trade-off. Real complications go unaddressed: risk of misprioritizing business-critical traffic, fairness/equity of who bears degraded service, SLA/contract exposure from shed requests.

10. Complete Trade-off Visibility — ✗ FAIL. No Cost Impact section, and specifically missing the real cost risk here: shedding traffic that turns out to be revenue-generating or contractually protected (SLA penalties).

11. No Significant Duplication — ✗ FAIL. Evidence: queue-non-urgent-requests.md and optimize-peak-cpu-utilization.md — the latter authored by the same submitter (dubrie), same publish date (2022-11-10) as this pattern — all three address the identical underlying goal: reduce over-provisioned standby capacity by flattening peak demand. optimize-peak-cpu-utilization.md explicitly names "queuing non-urgent requests" as an example technique within its own Solution, and shedding is the closely-related sibling tactic (drop vs. defer). All three even share near-identical SCI Impact bullet phrasing ("E: reduces energy... M: reduces hardware/embodied carbon..."). This is a genuine consolidation candidate, not three independent patterns.

Passes on: 1 (flagged), 2, 4, 6, 7, 8 Fails on: 3, 5, 9, 10, 11

To publish, requires:

Resolve the consolidation question first (see Recommendation) — decide whether this merges with queue-non-urgent-requests and optimize-peak-cpu-utilization into one broader "flatten peak demand" pattern (with shedding/queuing as named techniques within it) before investing further editing effort into it standalone.
If kept standalone: reframe as a requirements-stage decision — e.g., "Define traffic-priority tiers and acceptable degradation levels as a business requirement" — rather than the current operations/engineering framing.
Add a Cost Impact section covering the business-risk cost of shedding mis-prioritized or contractually-protected traffic.
Rewrite Considerations to address real friction: risk of misprioritization, fairness of degraded service, SLA exposure — not just an added implementation tip.

Recommendation: Consolidate — recommend a team discussion merging this with queue-non-urgent-requests and optimize-peak-cpu-utilization into a single broader "reduce peak capacity provisioning" pattern before doing standalone revision work that might be thrown away.

Cross-category summary

Pattern	Passes	Fails	Recommendation
Encrypt what is necessary	7	4 (4,5,8,10)	Revision
Match SLO to business needs	7	4 (5,8,9,10)	Revision
Optimize impact on customer equipment	4	7 (3,4,5,7,8,9,10)	Revision (substantial)
Shed lower priority traffic	6	5 (3,5,9,10,11)	Consolidation

Systemic issues across the whole Requirements category:

Every single pattern is missing Cost Impact. This isn't an isolated oversight — it's a category-wide gap. Worth flagging to whoever maintains the template/review checklist, since it suggests older submissions (all four are 2022–2023 vintage) predate stricter enforcement of Principle 10.
Two of four patterns (Encrypt, Match SLO) have Assumptions sections that are narrative/vague rather than testable — a recurring pattern-authoring habit worth calling out generally, not just per-pattern.
Two of four patterns (Optimize customer equipment, Shed traffic) have drifted into Development/Operations-style engineering language despite being filed under Requirements — this is the specific anti-pattern the skill's own guidance calls out by name, and it affects half this category.
Shed lower priority traffic has a real duplication problem with two patterns filed elsewhere in the catalogue — this is worth resolving before spending further editing effort on it in isolation.