Review before effect

What you'll do

Review synthetic source-read and deployment requests before any outward effect. Identify the target, operation, consent and definition binding. You will reject a changed plan rather than approving it from an old screenshot. No live source or Fabric operation is part of this exercise.

Distinguish explanation from execution

An assistant can explain a model or create a local draft without being authorised to connect to a database. A source-read operation crosses a different boundary from reading a supplied index. A Fabric upload, notebook run, refresh or export has its own execution scope and required authority.

The six-step source-to-report story is not one unattended command granting every later action. Source reads require explicit consent. Fabric execution checks workspace scope, consent and definition digests. Installation, a subscription or a helpful general prompt does not supply those decisions.

Read a source request precisely

Ask what data will be observed and where artifacts will be retained. Profiling, raw extraction and oracle capture are distinct operations. A value-free index does not imply that the profiling operation had no source exposure, and extraction can retain actual business data.

If the request names a source you cannot identify from approved project evidence, keep it pending. Do not invent a host, copy another project's connection details or ask for credentials in chat. Use the owning credential and consent workflow supplied by the approved project.

Synthetic approval worksheet
Target: the reviewed project asset
Operation: the exact proposed effect
Inputs: selected definition and plan bindings
Authority: the appropriate human and runtime scope
Stop condition: target or digest differs from the reviewed request

Bind deployment to what was reviewed

A digest-bound plan connects approval to specific definition bytes and intended operations. If the definition changes after review, the old approval cannot simply be applied to the new content. Regenerate and review the current plan through the owning workflow.

Use a failure case: the assistant adds a measure after a deployment plan was prepared. The user may still want the feature, but the reviewed digest no longer identifies the proposed definition. The correct response is to obtain a current plan and its required review, not to bypass the digest check or claim the old consent covers anything in that workspace.

Review the observed outcome too

Authorisation is not evidence that execution succeeded. After an approved action, inspect the producer result, ledger recording and required read-back or query observations. A successful upload does not establish refresh, semantic reconciliation or rendered report values. Keep those obligations separate in the handoff.

For the academy, annotate two fictional requests: one missing source-read consent and one whose deployment definition changed. State what can still proceed locally, such as reviewing the brief or correcting the draft. Then name the precise permission or evidence needed for the dependent action.

Your expected output is a decision record with target, operation, reason and next step. It does not authorise production or create a service. Human grain ratification and business acceptance remain separate even after every technical operation is consented and observed.

Check your understanding

1. Why does permission to inspect a source index differ from permission to extract rows?
2. What should happen when a definition changes after deployment-plan review?
3. Which observations are still needed after an authorised upload succeeds?