build-consulting-evidence-base

name

build-consulting-evidence-base

description

Deep-test a bounded consulting hypothesis or exploration question and return a traceable evidence packet for central adjudication. Use for public, private, local-file, interview, or mixed-source research that requires original-source pursuit, counterevidence, conflict reconciliation, sufficiency and saturation checks, or an actionable request for missing user-controlled data. Do not use to decide the overall recommendation, write the final storyline, design slides, or present transformed calculations as reported facts.

Build Consulting Evidence Base

Test one bounded question. Preserve the central lead's hypothesis, decision relevance, evidence need, route, support/refute/inconclusive conditions, and return contract. Do not rebuild the issue tree or decide the answer.

When invoked directly, ask only for a missing access, permission, recipient, or research-boundary fact that changes the work; otherwise state an assumption and proceed.

Match the evidence route to the decision need

Do not ask the user or central lead to choose a research level. Start from the bounded hypothesis and required knowledge grain. Expand original-source pursuit, rival testing, direct observation, or governed records only when a high-impact claim lacks direct evidence, a material conflict remains, the decision is hard to reverse, or one more feasible route could change the answer.

For each leaf, predeclare:

decision criterion → diagnostic question → falsifiable leaf test

Name its knowledge kind—claim verification, mechanism understanding, buyer/workflow understanding, economics, or implementation reality—and required grain: instance, aggregate, category, or derived. Category evidence cannot by itself prove an instance workflow, mechanism, economics, performance, or implementation reality.

Research by hypothesis

1. Map the evidence landscape, upstream sources, vocabulary, conflicts, and critical gaps briefly.
2. Open originals suited to the knowledge kind: primary documents/data, direct user or buyer evidence, implementation records, product trials, transactions, or authoritative regulation. Snippets and AI summaries are discovery only.
3. Extract the exact fact, population, period, unit, denominator, method, qualifier, applicability, and concrete instance or derived result required by the test.
4. Seek the strongest rival, counterexample, contradiction, and failure condition.
5. Run one targeted drill-down most likely to change the result or answer boundary.
6. Stop when another focused source is unlikely to change the test result or its decision-relevant confidence.

For each decision-critical instance-grade route evaluated, record exactly one route_result: attempted-with-evidence, attempted-empty, blocked, or infeasible (reason). Split documentary verification from live implementation or buyer validation when their outcomes differ; never combine two results in one route row. Never return sufficient_for_adjudication while a feasible direction-changing route lacks a recorded result. When the user or lead ends the timebox, open no new route: finish the current retrieval, record open routes, and return a narrowed, insufficient, or blocked packet.

Track material sources:

discovered → opened → read → claim-extracted → corroborated → decision-eligible

Shared upstream origin is not independent corroboration. Research depth is not source count. If the required grain remains unavailable, return insufficient, request direct observation or the smallest missing input when feasible, or narrow the claim.

For broad local folders, begin with a metadata-only inventory, establish a purpose-minimized allowlist, and exclude unrelated personal, identity, medical, HR, legal, duplicate, or archive material unless authorization specifically covers it.

Reconcile and bound claims

• Separate fact, estimate, forecast, inference, target, and recommendation.
• Reconcile conflicts through definitions, versions, periods, populations, denominators, methods, and source authority—not averaging or voting.
• Use company-controlled sources for documented features, terms, prices, or claims, not alone for pain, adoption, outcomes, willingness to pay, superiority, or implementation feasibility.
• Verify decision-relevant numbers and keep citations adjacent to the supported claim and underlying source.
• Route any new multi-input calculation, model, scoring, scenario, or sensitivity to $execute-consulting-analysis.

Use one explicitly labeled Mechanism card only when a decision-critical mechanism, workflow, economics, or implementation claim spans several sources or research rounds and no single evidence row explains the causal chain. Record actor | trigger/frequency | ordered steps | inputs/permissions/constraints | failure/workaround | decisive number | payer/cost bearer | locators; do not create it for simple claim verification.

Request and ingest user-controlled evidence

When inaccessible user-controlled data could change the result, use the canonical minimum_access_request in research-workflow.md: ask for the smallest purpose-limited extract, name an acceptable proxy and the claim it cannot replace, include stable Linkage: keys when joins are required, and state the narrower conclusion without access. Never request broad system access when a bounded or de-identified extract is enough.

Classify a return as user context/definition, management opinion, documentary evidence, or structured data. Context/opinion may change assumptions but are not facts. For evidence/data, confirm purpose, recipients, source/owner, version/date, and reuse boundary; reconcile population, period, fields, definitions, filters, denominator, grain, and linkage; test missingness, exclusions, duplicates, transformations, and selection effects; then apply the same lifecycle, independence, applicability, conflict, and numeric checks. Return its classification, highest source_state, evidence delta, and what it does and does not establish.

Return one packet

For each material test include:

• assigned hypothesis/test, knowledge kind, and grain;
• strongest support with exact locator and audience-eligible payload;
• strongest counterevidence/rival;
• directness, independence, applicability, limits, and reconciled conflicts;
• suggested support, refute, or inconclusive result;
• critical gap and smallest next step; and
• exactly one research state: sufficient_for_adjudication, insufficient, or blocked.

sufficient_for_adjudication means ready for the central lead to judge, not approved. When insufficient/blocked, preserve the current chain, rival, gap, minimum request, narrower conclusion, and missing knowledge kind/grain. Stop before recommendation, storyline, or design.

Use one researcher by default. Parallelize only mutually exclusive source branches or independent verification that can reconcile into one packet.

Load detail only when needed

• Read research-workflow.md for multi-round work, a minimum_access_request, or a returned-data loop.
• Read research-modes-and-tools.md when route choice is non-obvious or the work uses several source modes.
• Read source-discipline.md for private, interview, vendor-conflicted, mixed-source, or permission-sensitive evidence.
• Read quality-bar.md for consequential handoffs or after a packet fails central review.
• Use an asset template only when a durable packet helps.