Ratify with a human record

What you'll do

Prepare a human grain-review record for a synthetic Sales contract. Distinguish a validated draft, an authorised ratification and fixture-only test evidence. Your output is a reviewer packet and, only where a real authorised decision exists, a new ratified contract.

Ask for an actual decision

Ratification confirms the business meaning of each fact. Present the grain, included population, candidate key, amount definitions, unknown-member policy and remaining assumptions. The reviewer must understand what they are confirming. A request that says only "approve the model" hides the most consequential choices.

Use the order-line example. Explain that an order with three lines contributes three fact rows, while an order count requires its own correct measure semantics. Show how returns and cancelled lines are included or excluded. If those choices remain unresolved, keep the contract in draft form.

Preserve identity and words

The runtime requires the operator's reviewed identity and statement. An assistant can organise the packet and explain consequences; it cannot fabricate the reviewer or paraphrase an ambiguous discussion into approval. Silence is not ratification. A fixture identity from a demonstration belongs only to that demonstration.

Draft review prompt:
Confirm or reject the stated fact grain and population.
Identify unresolved exclusions or allocation rules.
Record the authorised reviewer's actual words separately.

This prompt is a request for a decision. It is not itself the ratification record. If the reviewer rejects the grain, revise the draft through the owning workflow, validate again and retain the reason. Do not edit a historical approval to make it fit the revised design.

Apply only the reviewed decision

The installed guide documents the following operation. Angle-bracket arguments are placeholders for the actual reviewed identity and verbatim statement, not suggested names or approval text:

❯node .agent-skills/powerbi/dimensional-model/runtime/star.mjs ratify --draft design/sales-gold.draft.json --out contracts/gold.json --fact fact_sales --by <ratifier> --record "<verbatim confirmation>" --result evidence/ratify-result.json

Use the actual source-bound draft for your selected contract version and a new output. For Type 2 contracts the package also requires project-confined, digest-bound history inputs; the short snapshot example is not a complete history procedure. Follow the installed manual for that route.

Existing outputs are refused. For multiple facts, the guide requires distinct successive outputs and a final contract validated with require-ratified. That behaviour preserves decisions instead of silently overwriting them. Ratification records a human business decision; it does not run a source query, deploy a model or prove a monetary result.

Review the resulting claim

Read the new contract and result together. Confirm the selected fact, source binding and recorded words match the packet. Keep other facts visibly pending if they have not been reviewed. A partially reviewed multi-fact design must not be described as fully ratified.

For the academy exercise, a written explanation of who must decide and what they must confirm is sufficient. Do not seek client approval merely to complete a training worksheet. This distinction lets you learn the protocol without pretending to possess real delivery authority.

Check your understanding

1. Why is a fixture ratification insufficient for a client's contract?
2. What must change when a reviewer rejects the proposed population?
3. Which claims remain unproved after a genuine grain ratification?