Advanced Methodology Extensions

These techniques extend specific stages of /evolve-solution when the standard tool in that slot is insufficient. Each maps to exactly one stage. Use one extension at a time — stacking multiple extensions on a single run risks methodology theater.

When to use this skill

Do not invoke by default. Check first:

Extension 1 — Structural Diversity Enforcer (Stage 4 add-on)

Problem: five variants that all use the same mechanism but with different parameters are not a tournament — they are a parameter sweep. Structural diversity means different causal paths to the goal, not different settings.

How it works:

Before scoring begins, build a Mechanism Map:

variant_id: V1
mechanism: "cache the embedding, reuse on re-query"   # causal path
assumption_set: [embeddings are stable, queries repeat]
independent_of: [V2, V3]   # yes/no: does this variant's mechanism differ from Vn?

If any two variants share the same mechanism and assumption_set → merge them into one, or replace one with a genuinely different causal path.

Minimum diversity requirement: ≥2 mechanism axes must differ across the finalist field. Mechanism axes: computational path, data structure, timing, scope (local/global), direction (push/pull), trust assumption.

Extension 2 — PRM-lite Intermediate Scoring (Stage 4 add-on)

Problem: tournament oracle gives a final score but not intermediate credit. A variant that gets 70% of the way to the goal looks identical to one that fails at step 1. You can't steer the field from a scalar output.

PRM-lite protocol:

Decompose the task into N reasoning steps (3–7). For each step, score the variant's intermediate output on that step alone:

variant: V2
steps:
  - step: "retrieve relevant context"
    score: 0.85   # 0.0–1.0
    signal: "top-3 contains the answer 85% of the time"
  - step: "generate candidate answer"
    score: 0.40
    signal: "correct format but factual error in 60% of cases"
  - step: "verify answer against source"
    score: 0.10
    signal: "verification is skipped in 90% of traces"
final_score: 0.40
bottleneck_step: "verify"

The bottleneck step is the priority for the next mutation, not the final score.

Constraint: PRM-lite requires a decomposable oracle. If you cannot define intermediate steps before running the variant, this extension does not apply.

Extension 3 — Cross-Model Critic (Stage 5 replacement)

Problem: the standard Red-Team (Stage 5) uses a Claude skeptic to review a Claude-generated variant. Shared training data creates shared blind spots. High-confidence claims that both generate AND verify should face a model with different training.

Protocol:

Route the finalist + falsification contract to a different model for adversarial review. The prompt is context-blind (FL asymmetry rule):

"You are a falsification agent. Your only inputs are the claim and the code. Generate 3 test cases that would falsify this claim. Report: CONFIRMED / FALSIFIED / NEEDS-REAL-DATA. Do not consider how the code was built."

Required: the review model must be architecturally different from the generating model (different training corpus, different architecture family). Same-family variants of the same model do not satisfy the cross-model requirement.

When NOT to use: if the alternative model cannot run code or inspect the artifact type (e.g., a text-only model reviewing compiled output), use the standard Claude skeptic with an explicit limitation noted in caveats.md.

Extension 4 — Fraud Attack Simulator (Stage 5 add-on)

Problem: standard red-teaming checks quality and correctness. It does not simulate an adversary who is trying to exploit the variant for personal gain. Security, financial, and fraud-adjacent variants need a different attacker model.

Attacker personas (pick relevant ones):

For each persona: identify the top 2 attack surfaces in the variant, describe a concrete attack scenario, specify what the variant would need to prevent it.

Output: skeptic_verdict.md extended with fraud_attack_surfaces section.

Extension 5 — Simulation-to-Equation (Stage 6 add-on)

Problem: the winning variant is a simulation or black-box model. The Evidence Gate can verify that it works, but not WHY it works. An equation makes the mechanism transparent, auditable, and falsifiable by theory.

Protocol:

1. Generate N outputs from the simulation across a parameter range
2. Identify the dominant functional form (linear, power law, exponential, logistic) using log-log and semi-log plots
3. Fit the equation to the outputs
4. Compute residuals — residuals > 10% of output range = equation is incomplete
5. Report the equation with confidence bounds, not as a discovery but as a description of what the simulation does

Evidence level: the extracted equation is [INFERRED] from simulation outputs. It is NOT [VERIFIED-REAL] unless validated on data that was not used for fitting.

Status: ACTIVE — extensions for /evolve-solution Stages 4–6. When to choose: consult the trigger table at the top before invoking. Does not replace: docs/variant-tournament.md, docs/evidence-judge.md, or any Core stage — adds one specialized tool per slot.