semantic-layer-and-metric-governance

Name: semantic-layer-and-metric-governance
Author: vaquarkhan

19stars4forks

How to install semantic-layer-and-metric-governance?

vaquarkhan/data-engineering-agent-skills/semantic-layer-and-metric-governance

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill semantic-layer-and-metric-governance

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# Semantic Layer And Metric Governance
2
3	## Overview
4
5	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.
6
7	## When to Use
8
9	- defining or changing business metrics
10	- introducing a semantic or metric layer
11	- standardizing dimensions and filters across teams
12	- governing high-value shared KPIs
13
14	Do not rely on ad hoc BI formulas when a metric needs cross-team trust.
15
16	## Workflow
17
18	1. Define the metric contract.
19	Include:
20	- owner
21	- exact business meaning
22	- grain
23	- numerator and denominator logic
24	- filters and exclusions
25
26	2. Standardize shared dimensions and time logic.
27
28	3. Map consumers and expected use cases.
29	A metric used in finance, product, and operations may need stronger governance than a local team report.
30
31	4. Keep metric logic centralized where possible.
32
33	5. Version or migrate breaking metric changes deliberately.
34
35	## Common Rationalizations
36
37	\| Rationalization \| Reality \|
38	\| --- \| --- \|
39	\| "Everyone already knows what revenue means." \| Teams often carry different assumptions about refunds, timing, and exclusions. \|
40	\| "The BI layer can handle this locally." \| Local formulas multiply inconsistency and make audits harder. \|
41	\| "Minor metric changes do not need change management." \| Even small definition shifts can invalidate trend lines and stakeholder trust. \|
42
43	## Red Flags
44
45	- no named metric owner
46	- filters and exclusions are implicit
47	- the same KPI exists in multiple incompatible forms
48	- definition changes are shipped without communication
49
50	## Verification
51
52	- [ ] Metric ownership and business meaning are explicit
53	- [ ] Shared dimensions and filters are standardized
54	- [ ] Consumer impact is considered for metric changes
55	- [ ] Breaking definition changes have a migration or communication path

People who liked this also viewed

6 picks

Type

semantic-layer-and-metric-governance

19stars4forks

View on GitHub

How to install semantic-layer-and-metric-governance?

vaquarkhan/data-engineering-agent-skills/semantic-layer-and-metric-governance

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill semantic-layer-and-metric-governance

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Semantic Layer And Metric Governance
2
3	## Overview
4
5	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.
6
7	## When to Use
8
9	- defining or changing business metrics
10	- introducing a semantic or metric layer
11	- standardizing dimensions and filters across teams
12	- governing high-value shared KPIs
13
14	Do not rely on ad hoc BI formulas when a metric needs cross-team trust.
15
16	## Workflow
17
18	1. Define the metric contract.
19	Include:
20	- owner
21	- exact business meaning
22	- grain
23	- numerator and denominator logic
24	- filters and exclusions
25
26	2. Standardize shared dimensions and time logic.
27
28	3. Map consumers and expected use cases.
29	A metric used in finance, product, and operations may need stronger governance than a local team report.
30
31	4. Keep metric logic centralized where possible.
32
33	5. Version or migrate breaking metric changes deliberately.
34
35	## Common Rationalizations
36
37	\| Rationalization \| Reality \|
38	\| --- \| --- \|
39	\| "Everyone already knows what revenue means." \| Teams often carry different assumptions about refunds, timing, and exclusions. \|
40	\| "The BI layer can handle this locally." \| Local formulas multiply inconsistency and make audits harder. \|
41	\| "Minor metric changes do not need change management." \| Even small definition shifts can invalidate trend lines and stakeholder trust. \|
42
43	## Red Flags
44
45	- no named metric owner
46	- filters and exclusions are implicit
47	- the same KPI exists in multiple incompatible forms
48	- definition changes are shipped without communication
49
50	## Verification
51
52	- [ ] Metric ownership and business meaning are explicit
53	- [ ] Shared dimensions and filters are standardized
54	- [ ] Consumer impact is considered for metric changes
55	- [ ] Breaking definition changes have a migration or communication path

People who liked this also viewed

6 picks

Type