Transform an underspecified problem into a defensible methodological stack. Apply Situational Method Engineering: retrieve, tailor, and compose reusable method fragments according to context. Distinguish things that are often mislabeled as “methodologies,” shortlist the smallest sufficient set, verify current sources, and translate the selection into concrete artifacts, gates, tests, and metrics.

Do not treat the catalog as a checklist to maximize. Select by problem-to-method fit.

Infer the requested mode; ask only when the difference changes the deliverable materially.

1. Classify — label a supplied list by type, domain, role, and overlap.
2. Discover — find plausible families and candidates without selecting prematurely.
3. Select — compare candidates and recommend a minimal stack.
4. Deepen — research one chosen candidate, its variants, evidence, version, and implementation.
5. Operationalize — convert the chosen stack into stages, responsibilities, artifacts, gates, tests, and metrics.
6. Audit — find omissions, duplication, cargo culting, obsolete versions, and methods used outside their valid context.

Never compare unlike objects as direct alternatives. Assign every item one primary type:

Use references/00-taxonomy-selection.md for the complete axes, scoring rubric, method-card schema, and saturation rule.

Use SPEM, Essence, or ISO/IEC 24744 only when the method repository itself needs a formal metamodel or interoperable tooling. The compact card schema is the default.

Extract or state:

• intended outcome and decision to make;
• unit of analysis: organization, capital/project, portfolio, process, product, facility, asset, supply network, place, ecosystem, population, learning program, system, API, model, claim, or incident;
• lifecycle phase: explore, frame, design, plan, build, verify, deploy, operate, improve, or govern;
• uncertainty, reversibility, coupling, criticality, regulation, time, skills, and evidence constraints;
• required output: map, model, contract, plan, test, proof, control, decision, or metric.

For domain work, also record jurisdiction, geography, target population, observation period, decision horizon, technology/evidence maturity, baseline/counterfactual, and the authority or competence required. These are hard validity boundaries, not optional metadata.

Distinguish an unclear problem from an unclear solution. Use discovery approaches for the former and evaluation approaches for the latter.

Read only the files needed:

For a cross-domain problem, begin with the primary decision catalog and at most two adjacent domain catalogs. Add another only when a selected fragment is canonically owned there or a material hard gate remains uncovered. Route by decision and missing capability, not by every noun in the prompt. references/10-composition-patterns.md and references/11-source-registry.md do not count as domain catalogs. Do not load all references by default.

When a prompt says only “uncertainty,” identify the required output before routing: probability/statistical inference, decision choice, optimization, causal effect, forecast, risk treatment, or evidence confidence. Route statistical/probabilistic inference to 37; route choices, optimization, causal identification, and decision robustness to 08. Use both only when the statistical result is an input to a distinct decision or causal design.

For task analysis, route goal/subgoal decomposition and execution plans to Hierarchical Task Analysis (HTA); route expert cues, judgments, strategies, and cognitive demands to Cognitive Task Analysis (CTA). Both are owned by 35; use training (18) or UX (20) only for a distinct downstream design decision. Clarify ambiguous HTA: Health Technology Assessment is a different method in the same catalog. HTA is not Hierarchical Task Network (HTN) planning, and a cognitive walkthrough is not a substitute for eliciting expert cognition.

For credible task errors and recovery, select SHERPA in 35 with an HTA and practitioner evidence. For modeled execution time of practiced, error-free interaction, select GOMS/KLM in 20 with a specified interface and user method. For variability and couplings in everyday sociotechnical work, select FRAM in 06 with work evidence and scenario instantiations. These outputs answer different questions; do not load or compose all three by default.

Search by problem signal, deliverable, and failure mode—not only by familiar names. Include candidates from distinct roles where warranted:

• one backbone lifecycle or governance frame;
• zero to three analysis/design techniques;
• zero to two representations, standards, or contracts;
• one verification or assurance mechanism for material claims or critical actions;
• two to five outcome, quality, risk, flow, or learning metrics.

Do not count a standard, a notation, and a test as three rival “methodologies.” They may be complementary layers.

Reject a candidate before scoring when:

• its required inputs, skills, authority, data, or tooling do not exist;
• its output does not feed a real downstream decision or control;
• its overhead exceeds the risk or reversibility of the task;
• it assumes stability while the problem is exploratory or complex;
• it assumes iteration while certification requires a fixed baseline and traceability;
• it duplicates another selected item without adding a distinct role;
• evidence of suitability is only vendor marketing or name recognition;
• a draft version is being presented as a stable normative standard.

Use the rubric in references/00-taxonomy-selection.md. Score 0–4 for outcome fit, context fit, verifiability, evidence/maturity, composability, implementation feasibility, and proportionality. Compare scores only among candidates competing for the same stack role and decision output; never rank a backbone against a specialist or a mandatory gate. Treat safety, legal, and mandatory-standard fit as constraints, not compensable scores.

When precise weights are unjustified, present a qualitative comparison rather than fake numerical accuracy. Run sensitivity analysis when close scores depend on subjective weights.

Prefer a coherent stack over a famous method:

1. Backbone: govern the overall lifecycle or decision cadence.
2. Specialists: solve bounded subproblems.
3. Representation: make inputs, decisions, interfaces, or state machine-verifiable.
4. Assurance: attack failure modes and support confidence.
5. Measurement: detect value, flow, quality, risk, and escape.

Apply the subtraction test: remove each element and state what material capability is lost. Remove elements whose loss is negligible.

Do not perform equal-depth research on every candidate.

Pass A — option validation

• Confirm canonical name, owner/standards body, scope, status, and current stable version.
• For legal, tax, regulatory, clinical, environmental, spatial, or sector claims, confirm jurisdiction, effective date, competent authority, and applicability to the exact activity and unit of analysis.
• Read an authoritative overview or normative source.
• Check whether the candidate is a method, reporting guideline, certification body of knowledge, notation, or tool ecosystem.
• Find at least one source about limitations, empirical results, or implementation outside the promoter when stakes justify it.

Pass B — selected-method deep dive

• Read the primary specification, guide, or seminal paper.
• Compare relevant variants and the current stable release; label drafts explicitly.
• Extract prerequisites, steps, roles, inputs, outputs, tailoring rules, failure modes, adoption cost, and validation evidence.
• Translate the method into this problem's artifacts and acceptance tests.
• For high-stakes domain execution, identify the boundary between agent research/design and work requiring a licensed professional, accredited body, laboratory, field inspection, or public authority.

For technical claims, prefer official specifications, standards bodies, maintainers, and original research. Separate “the source defines” from “evidence shows it works.” Never claim universal efficacy from popularity.

Use the catalog and query-family rule in references/00-taxonomy-selection.md. Saturation means additional search is no longer changing the shortlist or risk controls—not that every named framework on the internet was collected.

Default output:

1. Problem classification — context, phase, criticality, and required output.
2. Taxonomy correction — what kinds of objects are being discussed.
3. Candidate matrix — candidate, type, role, when to use, when not to use, evidence/version, overhead, and fit.
4. Selected stack — backbone, specialists, representation, assurance, and metrics.
5. Rejected alternatives — only serious contenders, with reasons.
6. Operationalization — steps, owners, artifacts, gates, tests, and measures.
7. Research status — verified stable sources, drafts, uncertain claims, and remaining questions.

If the user asks only for a concise market map, stop after items 1–5. If the user asks to implement, continue through item 7.

• Preserve the difference between when not to use and a mere disadvantage.
• Distinguish alternatives from complements, prerequisites, and supersets.
• Name versions only after checking current status; attach an “as of” date to volatile standards.
• Label proprietary, certification-oriented, emerging, contested, and organization-local methods.
• Do not infer maturity from an acronym or standards number.
• Do not prescribe heavyweight formality to low-risk reversible work without a proportionality argument.
• Do not use Agile, Lean, design thinking, systems thinking, or “best practices” as catch-all labels.
• Do not let the selected method approve its own output; use an independent gate for critical work.
• Preserve negative results and rejected candidates so later agents do not repeat the same search.
• Treat metrics as sensors, not targets; note gaming risk and pair leading with lagging indicators.

• “Which methods should guide the refactoring of an API-contract compiler?” → read software, formal planning, testing, and the GACE source catalog; compose a stack rather than choose one acronym.
• “Our order process has stable steps but high defect and rework rates.” → compare DMAIC, PDCA, TOC, process mining, VSM, FMEA, and statistical control; avoid product-discovery frameworks as the backbone.
• “We need an auditable investigation from public sources.” → combine a review/search protocol, source evaluation, provenance, claim–evidence modeling, competing-hypothesis analysis, and coverage metrics.
• “Should this agent workflow use PDDL or HTN?” → classify planning structure, observability, state uncertainty, action model, and runtime cost before comparing formalisms.
• “Should we invest in a circular industrial technology after a laboratory result?” → combine maturity and scale-up evidence, balances/TEA, LCA, supply network, regulatory/process-safety gates, and staged investment economics; do not equate laboratory yield with commercial readiness.
• “Did this training program work?” → separate satisfaction, learning, workplace transfer, operational outcome, and causal attribution before choosing assessments and evaluation methods.
• “How should we launch this B2B offer?” → combine market evidence, STP/ICP, positioning, offer/price, route-to-market, launch readiness, retention, and causal measurement; a campaign is not a GTM strategy.
• “Should we redesign this service or only its interface?” → map the end-to-end service, actors, failures, capacity, information, and recovery before selecting UX, service-design, accessibility, and operational methods.
• “How should we distribute the same evidence-based content across channels?” → combine communication objectives, content lifecycle/model, channel roles, rights, accessibility, distribution preflight, and outcome evidence; do not create a platform-posting checklist.
• “Should this public decision use a consultation or citizen assembly?” → define actual decision space, participation promise, representation, evidence, deliberation, response, and evaluation before selecting the format.
• “How do we move a laboratory technology toward commercialization?” → combine opportunity evidence, TMA/TRL, maturation experiments, integration/manufacturing readiness, IP/regulatory/economic gates, demonstration, and staged investment.