Self-contained install. <skill-dir> is the directory holding this file: substitute its absolute path in the commands below and run them from the repository root. Read <skill-dir>/references/operating-rules.md before acting; it holds the toolkit's always-on rules, which this install cannot load on its own. This install has no safety hooks, so the approvals those rules describe rest on you and the agent rather than on an enforced gate.

BI Model

Implement or review the semantic logic already used by the repository's BI platform. Treat BI calculations and filters as part of metric lineage, not presentation-only details.

When to use

• Review or author LookML when Looker evidence is present.
• Review or author another BI semantic format only when its repository artifacts and conventions are detected.
• Align BI measures, dimensions, joins, filters, time behavior, and access rules with canonical contracts and model grain.
• Do not use for dbt/MetricFlow semantic artifacts; use the semantic-layer workflow for those.

Mode and prerequisites

Default silently to Work mode. Use Learn only when teaching is requested and Assessment only when evaluation without answers is requested or .ae/exercise.json requires it.

Require or mark missing:

• Canonical metric contract and acceptance cases.
• BI project root, local configuration, vendor evidence, version or dialect evidence, and existing examples.
• Upstream model grains, keys, relationships, field types, ownership, and intended consumers.

Detection and convention procedure

1. Read .ae/exercise.json and .ae/project.yml when present.
2. Inventory local BI directories, project/configuration files, model/view/dataset definitions, generated metadata, and downstream references.
3. Identify the vendor from explicit repository evidence. Detect LookML from Looker project artifacts, not from the request's generic use of “BI model.”
4. Infer file placement, naming, includes/imports, refinement or inheritance patterns, formatting, join syntax, measure types, time groups, access controls, and validation conventions from local examples.
5. If vendor or syntax evidence is split or absent, report the candidates and stop before authoring vendor syntax.
6. Trace each requested field or metric from its canonical contract through upstream model expressions into the BI definition.
7. Map all joins, relationship declarations, hidden filters, default filters, access filters, and aggregate-awareness behavior that can alter results.
8. Author the smallest native change or review the submitted artifacts using the checks below.

BI semantic checks

• Measures: formula, population, aggregation, units, nulls, distinctness, and non-additive behavior match the contract.
• Dimensions: source expression, type, labels, groups, allowed values, time zone, and privacy exposure are intentional.
• Joins: keys, relationship/cardinality declarations, required joins, and fanout controls match observed model grain.
• Scope: explores/datasets and included fields support intended questions without exposing unsafe join paths.
• Filters: hidden, default, always-on, row-level, and access filters are included in the business meaning.
• Reuse: extensions, refinements, shared views, and aliases do not create divergent duplicate definitions.
• Portability: syntax and features are supported by the detected vendor and repository version.

Evidence required

Cite the BI config, each definition file, upstream model expression, canonical contract clause, and consumer reference used. Labels and relationship declarations are intent, not proof of formulas, key uniqueness, or cardinality. Name unsupported or unreadable file formats and exclude them explicitly from consumer counts.

Use formal Evidence, Risk, Recommendation, and Verification findings with severity and confidence for reviews and material BI risks. For straightforward implementation, report Changed, Why, Verified, and Remaining uncertainty.

Failure modes

• Assuming Looker, Tableau, Power BI, Cube, or another vendor without repository evidence.
• Copying syntax from a different vendor or version.
• Treating a display label as the metric definition.
• Declaring a many-to-one relationship without grain or key evidence.
• Ignoring filters, time zones, symmetric-aggregate behavior, access rules, or hidden fields.
• Reimplementing a metric in BI when an authoritative reusable definition already exists.
• Claiming validation, query results, or deployed behavior from static files.

Output contract

For implementation, return # BI Model with: Changed; Why, including platform convention, upstream grain, and canonical contract alignment; Verified; Remaining uncertainty. For a review, add evidence-backed findings about joins, fanout, duplicated definitions, access, and consumer risk.

For implementation, show intended paths and concise native definitions. For review, lead with findings ordered by severity. If no BI platform is detected, return NOT DETECTED with searched paths and do not produce speculative vendor code.

Verification

• Walk one normal query path and one fanout or boundary scenario for each critical measure.
• Compare formulas, filters, units, and time semantics with the canonical contract.
• Confirm every construct against detected local examples and version evidence.
• Search BI, semantic, model, test, and exposure files for duplicate definitions and downstream references.
• Propose vendor validation steps as a user-run plan only; do not contact the platform or execute queries.

Safety and repository writes

• Local Basic only: use local files and user-provided material. Never call MCP, access a warehouse, execute dbt, or contact a BI service.
• Minimize field exposure and never print credentials, connection settings, raw personal data, or protected values.
• Explicitly requested reversible BI artifact edits may proceed without a second approval. Preview and obtain approval before changing metric meaning, access controls, shared contracts, deleting files, or expanding scope.
• Flag row-level security or access-filter changes as potentially broad disclosure risks.