Draft and validate the star

What you'll do

Turn a reviewed synthetic Sales design into a draft Gold contract and a validation checklist. Declare types, keys, conformed dimensions and reconciliation requirements. You need the process worksheet and source-map risks from the preceding lessons; this exercise does not compile notebooks or execute a source query.

Separate business design from file validity

A Gold contract describes the business-facing dimensional structures. Begin with the fact grain and population already proposed for review. Then define dimensions, relationships, measure specifications and independent checks. The contract records decisions in a machine-readable form; it does not make an undecided business definition authoritative.

A useful Sales draft connects a sales fact with customer, product, territory and date dimensions. Use names and casing from the selected source contract rather than assuming every source uses the same spelling. Keep an explicit unknown-member rule and identify which date role supports each reporting question.

Make precision a design decision

The package supports distinct contract versions. The documented v1 monetary projection uses double. The SQL Server v2 contract carries exact decimal policies and refuses stale precision bindings or float substitutions. Do not mix their guarantees.

In the SQL Sales proposal, revenue uses decimal(38,8) and prices decimal(19,4). Those are documented proposal choices, not universal prescriptions for every client. Specify the appropriate policy and review loss and rounding behaviour. Semantic projection still uses double, so preserving exact Gold decimals does not qualify the later semantic values.

Review checks:
- every fact amount belongs at the agreed grain
- every measure column has its required precision policy
- independent scalar and grouped reconciliations are declared
- unknown-member handling preserves accountable population

Validate the draft without inventing approval

After the design artifacts exist, the installed package documents this validation route:

❯node .agent-skills/powerbi/dimensional-model/runtime/star.mjs validate --brief design/sales-star-brief.md --contract design/sales-gold.draft.json --result evidence/draft-result.json

These are example project-relative paths from the package guide. Use a new result location and the actual approved lab inputs. Read the resulting checks. A successful structural validation says the draft satisfies the checked contract requirements; it is not ratification, source correctness or deployed Gold reconciliation.

A draft may initially have an unbound source digest. The documented bind-source operation produces a new bound draft rather than editing it in place. A ratified contract cannot retain an unbound source digest. If your source index is missing, keep that dependency unresolved rather than inserting a plausible hash.

Hand the draft to a reviewer

Submit the brief, draft contract, validation result and open decisions together. Include a failure example: a grouped revenue check detects a territory join error even when the global total matches. State which reconciliation observations will be collected later and who will author the independent expectations.

Your expected output is a valid, reviewable draft with honest limits. Gold compilation requires the separate ratification step. Generation, deployment, refresh and business acceptance remain distinct actions with their own evidence.

Check your understanding

1. Why does a valid contract still need grain ratification?
2. What precision limit remains after exact Gold decimals enter the semantic model?
3. Which grouped check could expose an error hidden by a matching grand total?