Method Selector

Purpose

Convert the framed problem and data profile into a small executable decision surface. Screen methods for load-bearing data, assumption, degeneracy, sensitivity, and scale risks before asking the human to choose.

This skill proposes and probes methods. The human chooses the method.

Preconditions

• G1 problem framing passed.
• Required output and evaluation criteria are known.
• Relevant data inventory or audit exists.
• planning/symbol_table.md and planning/model_assumptions.md exist when the problem needs them.

If these are missing, return to the producer skill rather than guessing.

Inputs

• Problem parse and classification.
• Data audit, including missingness, effective sample size, imbalance, cardinality, and distribution summaries.
• Literature analysis when available.
• Contest deadline, implementation language, interpretability needs, and compute limits.
• planning/session_config.json.
• Existing methods/Qx/qx_method_card.md and decision ledger when revising.

Workflow

1. Align the decision surface.

   • Invoke decision-prompt-builder before generating an open-ended shortlist.
   • Ask about human-owned trade-offs, not algorithm names.
   • Reuse answers already present in the decision ledger.

2. Derive method requirements.

   • Start from required output, hard constraints, data characteristics, validation criteria, explanation burden, and experiment budget.
   • Identify the failure modes that would make a method unusable.

3. Create a role-based shortlist.

   • One main_candidate: best fit to the chosen trade-off.
   • One usable_baseline: completes the real task and yields directly comparable outputs.
   • At most one conditional_fallback: differs in a meaningful mathematical way and has an explicit activation trigger.
   • If a simple reference cannot complete the real task, label it diagnostic_reference; it does not satisfy the baseline requirement.
   • Do not add a method merely to reach a candidate count.

4. Define method-specific risk checks.

   • Use the contract in references/risk-probe-contract.md.
   • Select only relevant assumption checks.
   • Always check output degeneracy or concentration with metrics appropriate to the output.
   • Bound probe runtime rather than source-line count.

5. Run the risk probe on the main candidate and usable baseline.

   • Use a representative slice or full-data diagnostic as appropriate; never rely only on the first rows.
   • The probe may use reusable scripts and may save detailed metrics, but its canonical output is one compact summary.
   • Probe the fallback only enough to establish that its trigger and risk profile are credible. Do not fully implement it.

6. Write canonical artifacts.

   • methods/Qx/qx_method_card.md
   • methods/Qx/probes/risk_probe_summary.json
   • Update planning/manifests/Qx.json if present.

7. Ask for the method choice.

   • Present the probe evidence through a choice card.
   • After the user answers, hand the exact answer to modeler-decision-logger for append-only capture in methods/Qx/qx_decisions.jsonl.
   • If no answer is available, stop. Do not create a placeholder decision file.

Method Card Contract

qx_method_card.md stays compact and contains:

# Qx Method Card

## Goal and success criteria

## Human constraints
- Output form:
- Priority:
- Unacceptable failure:
- Experiment budget:

## Shortlist
| ID | Role | Mathematical idea | Why eligible | Main risk | Implementation cost |

## Baseline validity
- Real task completed:
- Comparable output/metric:
- If no, classification: diagnostic_reference

## Risk-probe summary
| ID | Executability | Data/assumptions | Degeneracy | Sensitivity | Scale | Verdict |

## Fallback trigger
- Trigger:
- Evidence to evaluate:

## Compact history
- One line per material change, with decision_id when human-owned.

Do not maintain a separate iteration log for new work.