fpf-parity

What this skill IS

This is fairness assurance for comparisons, not bureaucracy. Before declaring one variant better than another, you must ensure the comparison was fair — same budget, same data, same measurement procedure. Without parity, dominance claims are unreliable.

When to invoke

• Before /fpf-selection when comparing variants with measurable indicators
• When comparing benchmark results across different conditions
• When a variant "won" but you're not sure the comparison was fair
• NOT needed for purely qualitative comparisons (e.g., architectural trade-offs)

Output

.fpf/characterizations/PAR-${CLAUDE_SESSION_ID}--<slug>.md

Constraints (quality bar)

• C1: All candidates listed explicitly
• C2: Budget per candidate stated and equal (compute, time, attempts)
• C3: Environment identical or differences noted with impact assessment
• C4: Indicators from CHR-* referenced — no ad-hoc metrics
• C5: Minimum 2 repetitions with variance reported
• C6: No hidden aggregation — multi-dimensional results, not single score

Format

# Parity Plan
- **ID:** PAR-...  **CHR:** CHR-...  **Created:** YYYY-MM-DD

## Candidates
(A / B / C — what is being compared)

## Comparator
- Who compares: (role/agent performing the evaluation)
- Comparison method: (automated test | manual review | benchmark harness | ...)

## Equal conditions
- Time window: (same cutoff)
- Budget per candidate: (equal compute/time/attempts)
- Environment: (versions, hardware, config — identical or noted)
- Data/fixtures: (same dataset, same seed-set)

## Measurement
- Indicators: (from CHR-*, subset for this comparison)
- Repetitions: (≥2, with variance reporting)
- Normalization: (explicit rule or "none" with justification)
- Missing data: (how to handle "unknown"/"not measured" — exclude, impute, or flag)

## Result
- Non-dominated set: ...
- Eliminated and why: ...
- valid_until: YYYY-MM-DD