Define and codify pattern evaluation criteria

[russelltrow]

What

Formalise Decision Confidence as the evaluation standard for all patterns (new and existing). Document the principle, assessment output format, and gatekeeping pattern rule in the green-software-pattern skill. Create a reusable template the team can use when reviewing patterns.

Why

The team currently lacks shared language for assessing patterns, leading to circular debate (service mesh pattern took 15 minutes with no decision). Decision Confidence provides objective criteria that replace subjective judgment and make assessment faster and consistent.

Success

• Decision Confidence principle is documented in the skill
• Assessment Output template is added to the skill with clear examples
• Gatekeeping pattern rule (concrete conditions, not vague language) is codified
• Team has reviewed and agreed on the criteria
• Service mesh pattern assessment demonstrates the framework in action

SoW

• Document Decision Confidence core principle in skill
• Add Assessment Output template with sections (Passes On / Fails On / To Publish, Requires)
• Add examples showing how to apply the template
• Document gatekeeping pattern rule (no vague conditions)
• Get team buy-in via GitHub consensus motion
• Publish service mesh pattern assessment as proof of concept

[russelltrow]

Core Principles for Pattern Evaluation

For Team Discussion — Q3 2026

---

Overview

These principles define what makes a pattern publication-ready. They apply to all patterns regardless of lifecycle phase or type. Some principles are established; others are new and require team agreement.

---

EXISTING PRINCIPLES (Already in Skill)

1. Fewer, Better, Broader Patterns

Principle: The catalogue prioritizes quality over quantity. Patterns should be comprehensive enough to be genuinely useful on their own, focused on coherent themes — "a chapter in a guidebook, not a footnote."

Status: Established. No change.

---

2. Patterns, Not Practices

Principle: A pattern describes what to do and why it reduces emissions, not how to implement it in specific frameworks or languages. Solutions are high-level and directional.

Status: Established. No change.

---

3. Honour the Submitter's Framing

Principle: If a submission signals a particular lifecycle phase or audience (design decision, procurement question, end-user behaviour), anchor the pattern there — even if you could write more confidently about downstream effects. Your job is to articulate the submitter's insight, not translate it into your domain.

Status: Established. No change.

---

4. Action on Resource Format

Principle: Titles describe a clear action on a clear resource: "Cache static data," "Reduce database queries." Not vague language like "Write efficient code" or "Better software."

Status: Established. No change.

---

5. Complete Required Sections

Principle: Every pattern must include: Description, Solution, SCI Impact (E→I→M→R order), Cost Impact, Assumptions, Considerations, References.

Status: Established. No change.

---

6. Conciseness Matters

Principle: Focus on highest-impact points, not exhaustive coverage. Three strong techniques concisely beat six with diminishing returns.

Status: Established. No change.

---

NEW PRINCIPLES (Requiring Team Agreement)

7. Decision Confidence

Principle: Every pattern must give a practitioner enough clarity to confidently take one of two actions:

1. Implement the pattern knowing it will deliver stated benefits in their context
2. Confidently decide the pattern does NOT apply to them and move on

If a practitioner finishes reading uncertain ("I'm not sure if this applies to me"), the pattern has failed.

Applies to: All pattern types (prescriptive and gatekeeping)

Evidence: All three validated patterns (AI models, typography, carbon-aware scheduling) naturally pass this test.

Tested against:

• Clarity of applicability: Can practitioners tell if it applies?
• Clarity of action: Do they know what to do?
• Trade-offs visible: Are costs and benefits both explained?
• Completeness: Are Assumptions and Considerations specific enough?

Service mesh example — FAILS:
Practitioners finish reading unsure whether a 5-service architecture needs a mesh, whether it solves their observability gap, or what to do instead. Decision paralysis, not clarity.

---

8. Specific, Testable Assumptions

Principle: All patterns must state concrete prerequisites that practitioners can check against their situation. No vague conditionals.

Required format:
"This pattern applies when [specific, checkable condition]"

Banned language:

• "if needed"
• "when appropriate"
• "if feasible"
• "only if you think X is necessary"

Good examples from validated patterns:

AI models pattern:

"Smaller or optimized models can meet the functional requirements of the application"

Carbon-aware scheduling pattern:

"Workloads can be executed in alternative regions without violating data sovereignty. Carbon intensity data for regions and time periods is available and reliable. Some workloads are deferrable and can tolerate flexible scheduling windows."

Bad example — Service mesh pattern:

"The application does not have compliance requirements for using a service mesh."

(This states one narrow exception, not the prerequisites for the pattern to work.)

Applies to: All pattern types

---

9. Real Complications in Considerations

Principle: Considerations must address actual friction points practitioners will hit, not theoretical edge cases. Patterns should help practitioners adapt when their situation doesn't perfectly match.

What good Considerations do:

• Name complications practitioners will actually encounter
• Suggest how to adapt the pattern when context varies
• Signal when the pattern may not work well

What bad Considerations do:

• List hypothetical edge cases
• Mention alternatives without explaining when to choose them
• Abandon practitioners who decide not to use the pattern

Good examples from validated patterns:

Typography pattern:

"System fonts vary across platforms... Custom fonts may be a brand requirement... Aggressive subsetting can cause missing characters... Font caching reduces per-session impact for returning users."

(This addresses real decisions practitioners face and variations they must navigate.)

Carbon-aware scheduling pattern:

"Moving workloads across regions may introduce data transfer overhead. Regulatory and compliance requirements may restrict region selection. Pausing and resuming training may introduce checkpoint overhead."

(Real friction points that could block the pattern.)

Bad example — Service mesh pattern:

"Consider alternative methods outside of a service mesh to fulfill application requirements, for example custom DNS servers or a configuration that is injected into the application."

(Mentions alternatives but doesn't help practitioners choose between them or understand when each applies.)

Applies to: All pattern types

---

10. Complete Trade-off Visibility

Principle: Both SCI Impact and Cost Impact are required. Practitioners need the full picture to make confident decisions about whether the pattern's benefits justify its costs.

What this means:

• Cost Impact section is not optional (even if small)
• Both sections must address what you gain AND what you lose
• Trade-offs between cost and emissions should be explicit

Good examples:

Typography pattern Cost Impact:

"Network egress costs decrease... Third-party font service costs may be eliminated... BUT design time increases upfront (one-time cost)."

Carbon-aware scheduling pattern Cost Impact:

"Compute costs may decrease... BUT data transfer costs may increase... monitoring tools add operational cost... potential cost increases if scheduling impacts SLAs."

Bad example — Service mesh pattern:

Cost Impact section is entirely missing. Practitioners can't weigh licensing costs, operational overhead, or infrastructure cost against emissions savings.

Applies to: All pattern types

---

How These Principles Work Together

Principle	Prevents	Ensures
Decision Confidence	Circular debate about whether a pattern applies	Practitioners know if it applies to them
Specific Assumptions	Vague conditionals ("if needed")	Practitioners can self-assess fit
Real Complications	Abandoning practitioners who rule out the pattern	Guidance for adaptation or alternatives
Trade-off Visibility	One-sided cost/benefit analysis	Informed decision-making

---

Relationship to Assessment Framework

These 10 principles form the foundation for the Assessment Output template (used when evaluating existing patterns for publication, revision, or deletion).

When a pattern fails against these principles, the Assessment Output shows:

• Which principles it violates (specific and testable)
• What revision is needed (concrete changes)
• Whether the pattern should be revised, consolidated, or deleted

Example: Service mesh pattern violates principles 7, 8, 9, and 10. Assessment recommends: "Return for revision on five specific points, or consolidate under Infrastructure Layer Adoption pattern."

---

Team Discussion Questions

1. Do you agree these 10 principles capture what makes a pattern publication-ready?

2. On Decision Confidence (7): Is this the right threshold, or should it be higher/lower? All three validated patterns pass comfortably.

3. On Assumptions (8): Should all Assumptions be testable, or are some context-setting Assumptions acceptable? Where do we draw the line?

4. On Complications (9): How deep should Considerations go? Are we asking authors to anticipate too much?

5. On Trade-offs (10): Should Cost Impact be required even for patterns with minimal cost implications?

6. Prioritization: If a pattern violates one principle but passes others, is it worth revising? Or should violations trigger deletion/consolidation?

7. Existing catalogue: Should we audit all 60+ patterns against these principles? If so, who owns this work?

---

Appendix: Validation

These principles were tested against three published patterns:

1. Use right-sized and energy-efficient AI models (Naveen Balani, Development)
2. Prioritise system-first typography selection based on user needs (Paula de Matos, Design)
3. Use carbon-aware scheduling and region selection for AI workloads (Naveen Balani, Operations)

All three patterns naturally pass all 10 principles. The service mesh pattern (under review) fails on principles 7, 8, 9, and 10.

This suggests the principles are:

• Not an over-correction for one weak pattern
• Universal across lifecycle phases (Requirements, Design, Development, Operations)
• Achievable (three published examples show they work)

[russelltrow]

Created as new branch - https://github.com/Green-Software-Foundation/patterns/tree/patterns-creator-skill/skills/green-software-pattern-creator

[russelltrow]

Pull Request opened to merge principles into repo - #422