Read the source map

What you'll do

Read a value-free source index and produce a risk worksheet covering keys, relationships and coverage. You will distinguish metadata inspection, profiling, oracle capture and raw extraction. Use an approved synthetic index; no database read is needed for the exercise.

Read coverage before conclusions

A source map describes observed structure and declared coverage. Coverage may be full-scan, a bounded sample or metadata-only. Those labels change what a finding supports. A uniqueness observation in a sample cannot establish uniqueness across the complete population. Metadata-only coverage cannot establish current null or orphan behaviour through absent row observations.

The documented index can contain tables, typed columns, nullability, declared and inferred keys, foreign keys, counts and bounded summary information. It excludes sample rows, top-N value lists and connection strings. "Value-free" does not make source metadata suitable for unrestricted publication: names and structure can still reveal business context.

Trace one relationship

In the synthetic Sales model, follow the order-header key into the line table. Check the declared cardinality and whether the line's candidate key includes both order and line identifiers. Then inspect the route from a line to product, customer and calendar attributes.

Write down a question whenever the map cannot decide business meaning. Does a missing product represent a valid unknown member, an extraction omission or a rejected record? An orphan count exposes the issue; it does not choose the policy. Resolve the policy before a join silently removes facts.

Relationship: Sales line -> Product
Observed risk: unmatched product keys
Coverage: record the index's declared coverage
Decision needed: unknown member, quarantine or refusal

Keep four operations separate

Profiling builds structural and aggregate observations. Oracle capture executes independently authored expectations. Extraction retains business data for downstream processing. Scanning an existing index checks its declared shape and confidentiality constraints. None should silently stand in for another.

The installed PostgreSQL index scan is documented as:

❯node .agent-skills/powerbi/source-map/source.mjs scan --index <project-dir>/sources/<sourceId>/index.json --schema

Replace placeholders only from the approved lab manifest. This is not a command to connect to an invented source. A live profile, oracle or extraction requires explicit source-read consent and the correct source-specific route. SQL Server uses its documented SQL-specific runtime; do not substitute connection arguments by analogy.

Produce a usable risk worksheet

Choose three risks from the index: ambiguous grain, incomplete coverage, key duplication, null handling or relationship orphans. For each, record the observed file and relevant metadata, the possible model effect and the next evidence needed. For example, an inner join with unmatched dimension keys may drop revenue; independent grouped reconciliation can reveal the loss.

Finish with a clear admission decision: sufficient to draft, insufficient to ratify, or blocked pending a named observation. Do not convert an incomplete scan into reassurance. The worksheet should let a reviewer decide what to investigate without receiving raw rows or credentials.

Check your understanding

1. What can a sampled uniqueness finding establish, and what remains unknown?
2. Why are profile counts different from independent revenue expectations?
3. Which evidence would you request before deciding how to handle orphan keys?