gh-lyndonkl-claude/skills/negative-contrastive-framing/resources/methodology.md

Negative Contrastive Framing Methodology

Table of Contents

1. Contrast Matrix Design
2. Boundary Mapping
3. Failure Taxonomy
4. Near-Miss Generation
5. Multi-Dimensional Analysis
6. Operationalizing Criteria
7. Teaching Applications

---

1. Contrast Matrix Design

Concept

Systematically vary dimensions to explore boundary space between pass/fail.

Building the Matrix

Step 1: Identify key dimensions

• What aspects define quality/success?
• Which dimensions are necessary? Sufficient?
• Common: Quality, Speed, Cost, Usability, Accuracy, Completeness

Step 2: Create dimension scales

• For each dimension: What does "fail" vs "pass" vs "excellent" look like?
• Make measurable or at least clearly distinguishable

Step 3: Generate combinations

• Vary one dimension at a time (hold others constant)
• Create examples at: all-pass, single-fail, multi-fail, all-fail
• Focus on single-fail cases (most instructive)

Example: Code Quality

Example	Readable	Tested	Performant	Maintainable	Verdict
Ideal	✓	✓	✓	✓	PASS
Readable mess	✓	✗	✗	✗	FAIL (testability)
Fast spaghetti	✗	✗	✓	✗	FAIL (maintainability)
Tested but slow	✓	✓	✗	✓	BORDERLINE (performance trade-off acceptable?)
Over-engineered	✗	✓	✓	✗	FAIL (unnecessary complexity)

Insights from matrix:

• "Tested but slow" reveals performance is sometimes acceptable trade-off
• "Readable mess" shows readability alone insufficient
• "Over-engineered" shows you can pass some dimensions while creating new problems

Application Pattern

1. List 3-5 critical dimensions
2. Create 2×2 or 3×3 matrix (keeps manageable)
3. Fill diagonal (all pass, all fail) first
4. Fill off-diagonal (single fails) - THESE ARE YOUR NEAR-MISSES
5. Analyze which single fails are most harmful
6. Derive decision rules from pattern

---

2. Boundary Mapping

Concept

Identify exact threshold where pass becomes fail for continuous dimensions.

Technique: Boundary Walk

For quantitative dimensions:

1. Start at clear pass: Example clearly meeting criterion
2. Degrade incrementally: Worsen one dimension step-by-step
3. Find threshold: Where does it tip from pass to fail?
4. Document why: What breaks at that threshold?
5. Test robustness: Is threshold consistent across contexts?

Example: Response Time (UX)

• 0-100ms: Instant (excellent)
• 100-300ms: Slight delay (acceptable)
• 300-1000ms: Noticeable lag (borderline)
• 1000ms+: Frustrating (fail)
• Threshold insight: 1 second is psychological boundary where "waiting" begins

For qualitative dimensions:

1. Create spectrum: Order examples from clear pass to clear fail
2. Identify transition zone: Where does judgment become difficult?
3. Analyze edge cases: What's ambiguous about borderline cases?
4. Articulate criteria: What additional factor tips decision?

Example: Technical Jargon (Communication)

• Spectrum: No jargon → Domain terms explained → Domain terms assumed → Excessive jargon
• Transition: "Domain terms assumed" is borderline
• Criteria: Acceptable if audience is domain experts; fails for general audience
• Boundary insight: Jargon acceptability depends on audience, not absolute rule

Finding the "Almost" Zone

Near-misses live in transition zones. To find them:

• Identify clear passes and clear fails
• Generate examples between them
• Find examples that provoke disagreement
• Analyze what dimension causes disagreement
• Make that dimension explicit in criteria

---

3. Failure Taxonomy

Concept

Categorize failure modes to create comprehensive guards.

Taxonomy Dimensions

By Severity:

• Critical: Absolute disqualifier
• Major: Significant but possibly acceptable if compensated
• Minor: Weakness but not disqualifying

By Type:

• Omission: Missing required element
• Commission: Contains prohibited element
• Distortion: Present but incorrect/inappropriate

By Detection:

• Obvious: Easily caught in review
• Subtle: Requires careful inspection
• Latent: Only revealed in specific contexts

Building Failure Taxonomy

Step 1: Collect failure examples

• Real failures from past experience
• Hypothetical failures from risk analysis
• Near-misses that were caught

Step 2: Group by pattern

• What do similar failures have in common?
• Name patterns memorably

Step 3: Analyze root causes

• Why does this pattern occur?
• What misconception leads to it?

Step 4: Create detection + prevention

• Detection: How to spot this pattern?
• Prevention: What guard prevents it?

Example: API Design Failures

Failure Pattern 1: Inconsistent Naming

• Description: Endpoints use different naming conventions
• Example: /getUsers vs /user/list vs /fetch-user-data
• Root cause: No style guide; organic growth
• Detection: Run naming pattern analysis
• Prevention: Establish and enforce convention (e.g., RESTful: GET /users)

Failure Pattern 2: Over-fetching

• Description: Endpoint returns much more data than needed
• Example: User profile endpoint returns all user data including admin fields
• Root cause: Lazy serialization; security oversight
• Detection: Check payload size; audit returned fields
• Prevention: Field-level permissions; explicit response schemas

Failure Pattern 3: Breaking Changes Without Versioning

• Description: Modifying existing endpoint behavior
• Example: Changing field type from string to number
• Root cause: Not anticipating backward compatibility needs
• Detection: Compare API schema versions
• Prevention: Semantic versioning; deprecation warnings

Taxonomy Benefits:

• Systematic coverage of failure modes
• Reusable patterns across projects
• Training material for new team members
• Checklist for quality control

---

4. Near-Miss Generation

Concept

Systematically create examples that almost pass but fail on specific dimension.

Generation Strategies

Strategy 1: Single-Dimension Degradation

• Take a clear pass example
• Degrade exactly one dimension
• Keep all other dimensions at "pass" level
• Result: Isolates effect of that dimension

Example: Job Candidate

• Base (clear pass): Strong skills, culture fit, experience, communication
• Near-miss 1: Strong skills, culture fit, experience, poor communication
• Near-miss 2: Strong skills, culture fit, no experience, communication
• Near-miss 3: Strong skills, poor culture fit, experience, communication

Strategy 2: Compensation Testing

• Create example that fails on dimension X
• Excel on dimension Y
• Test if Y compensates for X
• Reveals whether dimensions are substitutable

Example: Product Launch

• Near-miss: Amazing product, terrible go-to-market
  • Question: Can product quality overcome poor launch?
  • Insight: Both are necessary; excellence in one doesn't compensate

Strategy 3: Naive Solution

• Imagine someone with surface understanding
• What would they produce?
• Often hits obvious requirements but misses subtle ones

Example: Data Visualization

• Naive: Technically accurate chart, misleading visual encoding
• Gets data right but fails communication goal

Strategy 4: Adjacent Domain Transfer

• Take best practice from domain A
• Apply naively to domain B
• Often creates near-miss: right idea, wrong context

Example: Agile in Hardware

• Software practice: Frequent releases
• Naive transfer: Frequent hardware prototypes
• Near-miss: Prototyping is expensive in hardware; frequency limits differ

Making Near-Misses Instructive

Good near-miss characteristics:

1. Plausible: Someone might genuinely produce this
2. Specific failure: Clear what dimension fails
3. Reveals subtlety: Failure isn't obvious at first
4. Teachable moment: Clarifies criterion through contrast

Weak near-miss characteristics:

• Too obviously bad (not genuinely "near")
• Fails on multiple dimensions (can't isolate lesson)
• Artificial/strawman (no one would actually do this)

---

5. Multi-Dimensional Analysis

Concept

When quality depends on multiple dimensions, analyze their interactions.

Necessary vs Sufficient Conditions

Necessary: Must have to pass (absence = automatic fail) Sufficient: Enough alone to pass Neither: Helps but not decisive

Analysis:

1. List candidate dimensions
2. Test each: If dimension fails but example passes → not necessary
3. Test each: If dimension passes alone and example passes → sufficient
4. Most quality criteria: Multiple necessary, none sufficient alone

Example: Effective Presentation

• Content quality: Necessary (bad content dooms even great delivery)
• Delivery skill: Necessary (great content poorly delivered fails)
• Slide design: Helpful but not necessary (can present without slides)
• Insight: Both content and delivery are necessary; neither sufficient alone

Dimension Interactions

Independent: Dimensions don't affect each other Complementary: Success in one enhances value of another Substitutable: Can trade off between dimensions Conflicting: Improving one tends to worsen another

Example: Software Documentation

• Accuracy × Completeness: Independent (can have both or neither)
• Completeness × Conciseness: Conflicting (trade-off required)
• Clarity × Examples: Complementary (examples make clarity even better)

Weighting Dimensions

Not all dimensions equally important. Three approaches:

1. Threshold Model:

• Each dimension has minimum threshold
• Must pass all thresholds (no compensation)
• Example: Safety-critical systems (can't trade safety for speed)

2. Compensatory Model:

• Dimensions can offset each other
• Weighted average determines pass/fail
• Example: Hiring (strong culture fit can partially offset skill gap)

3. Hybrid Model:

• Some dimensions are thresholds (must-haves)
• Others are compensatory (nice-to-haves)
• Example: Product quality (safety = threshold, features = compensatory)

---

6. Operationalizing Criteria

Concept

Turn fuzzy criteria into testable decision rules.

From Fuzzy to Operational

Fuzzy: "Intuitive user interface" Operational:

• ✓ Pass: 80% of new users complete core task without help in <5 min
• ✗ Fail: <60% complete without help, or >10 min required

Process:

Step 1: Identify fuzzy terms

• "Intuitive," "clear," "high-quality," "good performance"

Step 2: Ask "How would I measure this?"

• What observable behavior indicates presence/absence?
• What test could definitively determine pass/fail?

Step 3: Set thresholds

• Where is the line between pass and fail?
• Based on: standards, benchmarks, user research, expert judgment

Step 4: Add context conditions

• "Passes if X, assuming Y"
• Edge cases requiring judgment call

Operationalization Patterns

For Usability:

• Task completion rate
• Time on task
• Error frequency
• User satisfaction scores
• Needing help/documentation

For Code Quality:

• Cyclomatic complexity < N
• Test coverage > X%
• No functions > Y lines
• Naming convention compliance
• Passes linter with zero warnings

For Communication:

• Reading level (Flesch-Kincaid)
• Audience comprehension test
• Jargon ratio
• Example-to-concept ratio

For Performance:

• Response time < X ms at Y percentile
• Throughput > N requests/sec
• Resource usage < M under load

Handling Ambiguity

Some criteria resist full operationalization. Strategies:

1. Provide Examples:

• Can't define perfectly, but can show instances
• "It's like these examples, not like those"

2. Multi-Factor Checklist:

• Not single metric, but combination of indicators
• "Passes if meets 3 of 5 criteria"

3. Expert Judgment with Guidelines:

• Operational guidelines, but final call requires judgment
• Document what experts consider in edge cases

4. Context-Dependent Rules:

• Different thresholds for different contexts
• "For audience X: criterion A; for audience Y: criterion B"

---

7. Teaching Applications

Concept

Use negative examples to accelerate learning and pattern recognition.

Pedagogical Sequence

Stage 1: Show Extremes

• Clear pass vs clear fail
• Build confidence in obvious cases

Stage 2: Introduce Near-Misses

• Show close calls
• Discuss what tips the balance
• Most learning happens here

Stage 3: Learner Generation

• Have learners create their own negative examples
• Test understanding by having them explain why examples fail

Stage 4: Pattern Recognition Practice

• Mixed examples (pass/fail/borderline)
• Rapid classification with feedback
• Build intuition

Designing Learning Exercises

Exercise 1: Spot the Difference

• Show pairs: pass and near-miss that differs in one dimension
• Ask: "What's the key difference?"
• Reveals whether learner understands criterion

Exercise 2: Fix the Failure

• Give near-miss example
• Ask: "How would you fix this?"
• Tests whether learner can apply criterion

Exercise 3: Generate Anti-Examples

• Give positive example
• Ask: "Create a near-miss that fails on dimension X"
• Tests generative understanding

Exercise 4: Boundary Exploration

• Give borderline example
• Ask: "Pass or fail? Why? What additional info would help decide?"
• Develops judgment for ambiguous cases

Common Misconceptions to Address

Misconception 1: "More is always better"

• Show: Over-engineering, feature bloat, information overload
• Near-miss: Technically impressive but unusable

Misconception 2: "Following rules guarantees success"

• Show: Compliant but ineffective
• Near-miss: Meets all formal requirements but misses spirit

Misconception 3: "Avoiding negatives is enough"

• Show: Absence of bad ≠ presence of good
• Near-miss: No obvious flaws but no strengths either

Feedback on Negative Examples

Good feedback format:

1. Acknowledge what's right: "You correctly identified that..."
2. Point to specific failure: "But notice that dimension X fails because..."
3. Contrast with alternative: "Compare to this version where X passes..."
4. Extract principle: "This teaches us that [criterion] requires [specific condition]"

Example: "Your API design (near-miss) correctly uses RESTful conventions and clear naming. However, it returns too much data (security and performance issue). Compare to this version that returns only requested fields. This teaches us that security requires explicit field-level controls, not just endpoint authentication."

---

Quick Reference: Methodology Selection

Use Contrast Matrix when:

• Multiple dimensions to analyze
• Need systematic coverage
• Building comprehensive understanding

Use Boundary Mapping when:

• Dimensions are continuous
• Need to find exact thresholds
• Handling borderline cases

Use Failure Taxonomy when:

• Creating quality checklists
• Training teams on anti-patterns
• Systematic risk identification

Use Near-Miss Generation when:

• Teaching/training application
• Need instructive counterexamples
• Clarifying subtle criteria

Use Multi-Dimensional Analysis when:

• Dimensions interact
• Trade-offs exist
• Need to weight relative importance

Use Operationalization when:

• Criteria too fuzzy to apply consistently
• Need objective pass/fail test
• Reducing judgment variability

Use Teaching Applications when:

• Training users/teams
• Building pattern recognition
• Accelerating learning curve