People and permissions

Name the decisions people own

Automation can draft a dimensional design, generate artifacts and compare observed results. It cannot invent a business owner's grain decision, a database owner's read approval or a customer's acceptance. Keeping those decisions explicit makes an engineering handover more useful. A reviewer can see what was authorised, what was observed and which decision remains outstanding.

In this lesson, build a synthetic responsibility worksheet. Use role names rather than real identities. List four decisions: ratifying the fact grain, approving source reads, consenting to deployment and accepting the business result. The same person may hold several roles in a small team, but the decisions remain distinct. One approval does not automatically authorise every later operation.

Ratify meaning with a human record

A domain seed supplies draft business-process meaning. A generated star contract turns that draft into a proposed structure. Neither supplies client approval. Before authoritative Gold compilation, a human must confirm the grain: what one fact row represents. Preserve the reviewer's actual decision and its context through the owning workflow. Do not copy a fixture reviewer's identity into a real project.

This matters when the question changes. An order-level analysis and an order-line analysis can both be legitimate, yet require different designs and expectations. A successful machine check cannot tell you which interpretation a customer commercially intended. Independent oracle review and grain ratification support that judgment; they do not remove the need to make and record it.

Keep consent bound to the effect

Installation is not permission to read a source or deploy to Fabric. Source profiling, extraction and oracle capture are distinct requests. Each must respect its approved scope. For Fabric operations, review workspace scope, definition digests and the exact execution plan before effect. A changed artifact or target can change what an earlier approval covered.

Generation also differs from publication. Producing semantic definitions does not deploy or refresh them. A report export may contain business values. Review the operation actually requested and its destination, rather than treating a broad “build the report” instruction as unlimited authority. This course teaches the boundary; live operations require the approved lab and current package instructions.

Separate access from qualification

Hosted is a protected preview with current membership, exact grants and entitlements checked separately. A role, subscription or OAuth scope alone does not grant project access. A local authoring assistant and Hosted read-only MCP have different capabilities and data boundaries. Information supplied to an external assistant follows that provider's controls, so the narrower Hosted no-values promise must not become a claim that nothing crosses a network.

Keep raw receipts, oracle values and report images in customer-controlled evidence custody. A value-free signed attestation is a separate projection. Its signature authenticates the exact claim, and a signed Hosted acknowledgement records acceptance of the envelope under Hosted authority. Neither substitutes for the independent local comparison or business acceptance.

Decision	Preserve separately from
Grain ratification	Generated model definitions
Source-read approval	Tool installation
Exact-plan deployment consent	A previous artifact or workspace approval
Business acceptance	Machine pass and trusted signatures

Completion check

Write a bounded task for a synthetic Sales draft: state the requested artifact, the available evidence and the stopping point before an external effect. Then identify who owns each of the four decisions. Explain why a signed passing gate still cannot create a human acceptance record. Finish by naming the local, Fabric, assistant-provider and Hosted boundaries without claiming that one permission covers them all.