Reads and filters certified products on the shared upstream model — does not build private semantics or a tool-local parallel model.
Tool depth
Basis — viewer / consumer rights in BI
Typical work
- Read reports and dashboards
- Filter and slice within approved bounds
- Export only where allowed
Does
- Use certified numbers and products
- Raise gaps and divergence
- Consume the same upstream truth as every other tier
Does not
- Create a private semantic model or competing base measures
- Redefine protected metric names
- Spread uncontrolled shadow as a decision basis
When it fits
- Operational or leadership reports without modeling
- Consistent numbers matter more than ad-hoc freedom
Ad-hoc and local slices can exist on the approved model. Controlled local work needs label, owner, expiry, and no claim to be the enterprise source of truth.
Tool depth
Advanced — explorer / self-service on the semantic layer
Typical work
- Ad-hoc analysis and exploration
- Allowed derivatives from base metrics
- Time-box and label experiments
Does
- Filter, slice, and hypothesize on the shared basis
- Keep local exploratory metrics with owner and expiry
- Trigger promotion to the steward when reuse appears
Does not
- Label local formulas as governed
- Silently change population, grain, or base measures
- Distribute uncontrolled shadow to multiple decision makers
When it fits
- Business questions faster than the product backlog
- Hypotheses that do not yet need a metric contract
Builds dashboards and presentation logic on the shared model. Power in BI means layout and allowed measures — not a second semantic model as system of record.
Tool depth
Power in BI — author / developer, bound to the semantic layer
Typical work
- Dashboards and report layouts
- Presentation and interaction
- Measures only by approved patterns
Does
- Deliver visual products on marts and the semantic layer
- Shape grain and contracts with architect/steward (bridge)
- Inventory tool-local duplicates and migrate them upstream
Does not
- Run a competing business model per tool
- Decide interface standards and breaking changes alone
- Publish shadow models as certified truth
When it fits
- Recurring reports for teams or leadership
- Presentation logic that does not redefine the shared model
Models, stats, and ML on approved extracts and contracts. A separate skill line — not a substitute for the BI semantic model and not a parallel enterprise truth.
Tool depth
Specialist — R / Python / notebooks / ML, not “Power BI power user”
Typical work
- Statistics, forecasting, experiments
- Feature engineering in the sandbox
- Feed results back with TTL and a contract
Does
- Work on contract extracts and approved features
- Keep sandbox clearly separate from production truth
- Promote features/scores via steward/architect
Does not
- Publish notebook logic as an unmarked BI base measure
- Run training copies as a lasting shadow system of record
- Bypass PII or purpose bounds in the sandbox
When it fits
- Hypotheses and models beyond classic BI reports
- Experiments with a clear end date and owner
Domain method plus data (e.g. market analysis) on the same upstream basis. Method and scenarios may be local — metric truth and population may not.
Tool depth
Deep in the domain — often not “Power BI power”, but the same data basis
Typical work
- Business scenarios and assumptions
- Methodical analysis on approved products
- Label outcomes as scenarios
Does
- Make scenarios and assumptions explicit
- Use the same base metrics and population as report and BI
- Escalate need for new definitions to the steward
Does not
- Run a private “market” truth as an unmarked enterprise metric
- Use tool-local models as a substitute for lake/warehouse semantics
- Base critical decisions on uncontrolled shadow
When it fits
- Pricing, market, risk method, or similar disciplines
- Scenario work with a clear split from governed base
