Semantic layer and metric governance
Skill vaquarkhan/data-engineering-agent-skills/skills/semantic-layer-and-metric-governance
Production-grade Agent Skills for data engineering AI agents: 73 workflows, platform presets, safe backfill/replay, Kafka & Spark reliability, MCP observability, and VS Code/JetBrains installers.
npx -y skills add vaquarkhan/data-engineering-agent-skills --skill semantic-layer-and-metric-governanceAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 21 stars21 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Guides agents through semantic layer and shared metric design. Use when defining business metrics, reusable dimensions, governed metric contracts, or shared semantic models consumed by dashboards, analytics tools, or other teams.
SKILL.md
2.1 KB, 374 tokens by cl100k_base, as published. Nobody here has run it
Semantic Layer And Metric Governance
Overview
Use this skill when the challenge is consistency of meaning, not just correctness of rows. It helps agents define shared metrics and dimensions so teams stop rebuilding conflicting logic in every downstream tool.
When to Use
- defining or changing business metrics
- introducing a semantic or metric layer
- standardizing dimensions and filters across teams
- governing high-value shared KPIs
Do not rely on ad hoc BI formulas when a metric needs cross-team trust.
Workflow
-
Define the metric contract. Include:
- owner
- exact business meaning
- grain
- numerator and denominator logic
- filters and exclusions
-
Standardize shared dimensions and time logic.
-
Map consumers and expected use cases. A metric used in finance, product, and operations may need stronger governance than a local team report.
-
Keep metric logic centralized where possible.
-
Version or migrate breaking metric changes deliberately.
Common Rationalizations
| Rationalization | Reality |
|---|---|
| "Everyone already knows what revenue means." | Teams often carry different assumptions about refunds, timing, and exclusions. |
| "The BI layer can handle this locally." | Local formulas multiply inconsistency and make audits harder. |
| "Minor metric changes do not need change management." | Even small definition shifts can invalidate trend lines and stakeholder trust. |
Red Flags
- no named metric owner
- filters and exclusions are implicit
- the same KPI exists in multiple incompatible forms
- definition changes are shipped without communication
Verification
- Metric ownership and business meaning are explicit
- Shared dimensions and filters are standardized
- Consumer impact is considered for metric changes
- Breaking definition changes have a migration or communication path
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.