Metric Semantic Layer: How Lyft Governs and Scales Key Data Definitions

Summary

As Lyft scaled, different teams developed conflicting definitions for key business metrics due to the lack of centralized version control and shared standards. To resolve this, Lyft implemented an internal Metric Semantic Layer as a Python package that stores authoritative metric definitions in YAML files with Jinja SQL templates. The system restricts onboarding to Golden Metrics used across multiple applications, requiring team-based approval from both Business and Operational Owners for any definition changes. Standardized definitions are exposed through Python APIs, integrated into the Amundsen data catalog and self-service user interfaces, and surfaced to AI tools via a Model Context Protocol.

Context

As Lyft grew, products and teams evolved without centralized version control or a shared metric standard. Consequently, different teams created inconsistent definitions for identical metrics, allowing outdated definitions to influence operational decisions, key forecasts, and hypothesis testing.

Approach / What changed

Lyft built the Metric Semantic Layer (MSL) as a Python package using YAML configurations and Jinja SQL templates to decouple metric logic across granularities and dimensions. Governance is enforced by onboarding only Golden Metrics with at least two use cases and mandating dual team-level ownership across Business and Operational owners for metric changes. MSL definitions are exposed via Python APIs, automated downstream code refactoring, Amundsen catalog integration, a no-code UI, and an MCP server for AI workflows.

Takeaways

• Golden Metrics require at least two distinct use cases to qualify for onboarding into MSL, preventing niche metrics from adding unnecessary governance overhead.
• Metric modifications mandate dual sign-off from a team-based Business Owner responsible for metric health and an Operational Owner responsible for underlying data pipelines and data quality.
• Exposing YAML metric definitions via a Model Context Protocol (MCP) enables natural-language querying by AI agents and BI tools while reducing hallucinations.

Related reading

• Red Hat · Aug 19, 2026

  Accelerate automation with AI and the Ansible development tools MCP servers

  Ansible automation development often involves frequent context switching and struggles with AI assistants generating syntactically valid code that hallucinates module parameters or misses local dependencies. To address this gap, the Ansible development tools Model Context Protocol server connects AI assistants to external development tooling through structured interfaces. The server wraps command-line utilities, enabling AI models to deterministically run ansible-lint with automatic fixes, scaffold projects via ansible-creator, manage environments, and build execution environment container images. By surfacing local workspace schemas, documentation, and organizational linting standards, the system grounds AI responses in real environment configurations. The integration operates across multiple MCP-compatible clients without requiring a specific model provider.

  Leonardo Gallego

• Salesforce · Aug 24, 2026