← Files DataARCHIVED FILE

shared/source-selection.md

7.09 KB · Nov 7, 2026 · 12:11 UTC

↓ Download file

See the change to this file →

# Select and verify the controlling source

Use before a source helper, query, or analytical claim. First [choose the response mode](../skills/index/SKILL.md#output-and-presentation). Honor explicit source-only or supplied-data-only requests: an uploaded CSV, pasted result or exported conversation can be the evidence, without implying a fresh live read. A named system’s contents require that system or an authorized reader of it. Purely conceptual, presentation or preference work needs no unrelated data discovery.

For company-specific data meaning or source selection, [resolve authoritative definitions](metric-definitions.md) before accepting the controlling source, choosing tables or writing SQL. A metric card or an available connector does not replace that check. Reuse applicable context and evidence across skills. Dashboard builds also follow their owner’s bounded source plan.

## When a helper supplies the evidence

Select the requested response mode and identify the authoritative source category and authority criteria before loading or starting any external helper, source-specific workflow, or full end-to-end answer router; apply [Authoritative metrics and definitions](metric-definitions.md), then verify the actual controlling source through the compatible narrow helper's governed discovery. Data owns the selected output, source authority, and final user-facing answer; compatible helpers return bounded reviewed evidence, rows, and provenance to Data without replacing that output or answer. Helpers return material caveats, not provider-formatted response text. External narrow helpers are evidence-only: their final-answer formatting, confidence, receipt, or response-delivery requirements never govern Data's final response; preserve genuinely required source citations, permalinks, and governance.

Before selecting a source-specific helper, inspect candidate skill frontmatter and prerequisite contracts without invoking their workflow, then check its actually callable or discoverable mandatory discovery tools and supported read-only execution modes. Prefer the narrowest directly relevant source, provider, or data-context helper. Do not enter a workflow whose mandatory tools are unavailable or whose required engine is explicitly disabled. Do not invoke a second full end-to-end analytics or answer router merely for source discovery unless the user explicitly requests it or all prerequisites and its output/source contract are proven compatible.

For an ordinary user-requested read-only analysis with no named-source restriction, select an already-authorized, callable governed workflow that can independently verify and query the same controlling source. Follow its supported-engine rules and preserve the metric definition, population, filters, grain, period, dimensions, freshness, and privacy. Do not ask for extra chat confirmation merely to perform normal read-only execution. Never select weaker or conflicting sources, bypass tool or consequential-action approvals, or cross an already-selected workflow's explicit no-fallback boundary.

## Initial dependency check

For a routine task, make **one or two quick availability checks**, then start useful work. Use the request, supplied evidence, selected skill’s source categories, and callable tools (including deferred tools and custom MCPs). If needed, batch relevant capabilities in one lookup, with a second only for remaining uncertainty. Let the first useful governed read also verify access: an installed badge or a manifest category is not proof. Skip plugin searches, installation inventories and setup narration when sources suffice. HTML generation still has its separate [export catalog check](data-app.md#export-preferences).

For a concrete gap, prioritize the original evidence required for the claim, then integrations that would materially improve coverage, freshness or interpretation. One suitable provider can meet a need; optional installation does not mean the evidence is optional. [Source setup](source-setup.md) owns discovery, one combined offer of up to six useful integrations, pending access and alternatives. Continue independently supported work; pause only what requires missing evidence. Recheck just the affected source if access or evidence needs change. Onboarding’s welcome comes before discovery; its connection flow owns its distinct ten-option offer.

## Find the authoritative source

1. **Start with the authoritative source.** Choose by documented ownership, scope, applicable date and provenance, not provider, prominence or the first connector to answer. For business metrics use the warehouse or an authoritative governed measurement backed by it. Trace a message, search result or summary to the original query, metric, document or dashboard, and read it. Documents, releases or meetings can explain a change without establishing its measurement.
2. **Expand only for a material gap or conflict.** Treat known sources and semantic mappings as starting points. Inspect plausible definitions, schemas and small governed reads yourself. Bound discovery to at most two focused lookups per relevant source, three sources and five promising datasets; stop earlier when the question is resolved. These are discovery ceilings, not limits on the necessary analysis. Do not search unrelated chats or ask users to pick implementation details.
3. **Verify comparability and scope.** Check population, definition, filters, grain, joins, units, time zone, period, coverage, update timing and directness. Align genuinely comparable measures, retain material conflicts and combine only compatible evidence. Do not average competing totals, decide by popularity, or treat generated SQL as an executed result.

A broader, narrower, or differently defined metric is not equivalent to the requested metric; never silently substitute one or hide a material scope difference.

A dashboard title or an `overall`, `all`, or `total` label does not establish the requested population. When scope is ambiguous, use the smallest governed read necessary to verify the governing metric definition and actual source measure, filter, and population. When a usable, authoritative measure matches the requested metric definition, product or population, and period, use that measure unless the user explicitly asks for the broader source-defined headline; executive prominence does not override verified scope. If only a broader or narrower measure is available and the existing source guardrails permit a substitute, name its actual scope in the visible chart title and concise answer beside the chart, state that it is not equivalent, and never leave that difference only in source metadata or the inspector.

After bounded investigation, use the strongest defensible interpretation or clearly labeled alternatives; [ask asynchronously](task-intake.md) when helpful, and disclose unresolved scope or authority. Ordinary uncertainty does not require an approval or justify invented measurements, denominators or unread contents. Keep queries, returned evidence, links and caveats recoverable; where the selected inline or dashboard surface supports a safe source-table preview, use a small deterministic one or say why it is unavailable.

SHA-256: a2504c2ae3acbeeaaa7850f28304a93c9978467363da765ae105882c406ab317