Features
Features Overview
Overview of the ClariLayer app journey: author metrics in Metric Studio, reuse registry definitions, validate in the warehouse, release with governance, and serve API context.
Use this features overview when you want the public product map before reading individual feature pages or API reference material. ClariLayer is Metric Lifecycle Management software: it helps teams turn business metric intent into governed, versioned context that people, BI tools, and AI agents can reuse.
Read this page as the features overview for Metric Studio, registry discovery, validation, governance, trust signals, and API context.
The simple version is: author the metric, discover whether related definitions already exist, validate the definition against warehouse reality, govern the release, monitor trust signals, and serve the approved context through the Contract API. Each step contributes to the same context layer. Warehouses and semantic layers can compute numbers, but ClariLayer preserves what a number means, who owns it, which version is approved, when it should be used, and why it was shaped this way.
1. Author metrics
Metric Studio is where metric work starts. A business owner can describe intent in plain language, import existing SQL, or start from a template. The important output is not just SQL. ClariLayer captures the business definition, exclusions, grain, time-window semantics, source assumptions, owner, governance tier, and reasoning that reviewers will need later.
Authoring is designed for practical collaboration between business and technical teams. Business users bring the meaning. Analytics and data engineering teams bring warehouse context, implementation judgment, and review discipline. The product keeps those responsibilities attached to the same metric artifact instead of scattering them across tickets, chats, dashboards, and warehouse comments.
Read the Metric Studio feature page
2. Discover and reuse definitions
Before a team creates another revenue, churn, pipeline, or activation metric, they need to know what already exists. The registry is the discovery layer for governed definitions. It helps people find metrics by name, description, owner, lifecycle state, governance tier, validation recency, and version context. It also surfaces related or overlapping definitions so teams can reuse the right metric or create an explicit managed variant.
Managed variants are important because a single forced definition is not always honest. Finance, sales, marketing, and product teams may need different views of the same concept. ClariLayer makes those differences visible, versioned, and auditable instead of letting them become hidden metric drift.
Read the Metric Registry feature page
3. Validate definitions
Validation connects stated intent to warehouse reality. ClariLayer can run bounded checks against Databricks, Snowflake, or BigQuery for the shared catalog, validation, deployment, and rollback path. The checks are meant to answer practical questions: does the SQL compile, do expected sources exist, do basic integrity assumptions hold, and does the metric need more review before it becomes trusted context?
Validation evidence belongs to the metric version, not a one-off test log. That means later readers can see whether a definition is proven, stale, unverified, or blocked from promotion until evidence is refreshed. Observe and query-history ingestion remain Databricks-only today, so Snowflake and BigQuery evaluations should focus on catalog browse, validation, deploy, rollback, registry, and API context.
Read the Warehouse Validation docs
Read the Warehouse Validation feature page
4. Govern releases
Governance turns a good draft into a trusted version. ClariLayer treats release work as a lifecycle checkpoint with owner, policy tier, validation evidence, approval state, release history, and reasoning trail attached. Experimental definitions can move quickly, operational definitions can require validation and owner review, and financial definitions can require stronger approval before becoming safe for board-level reporting.
Releases should be immutable. If the business meaning changes, the next version carries its own definition, validation evidence, review context, and release history. That keeps people and AI consumers from silently inheriting changed logic without knowing which version they used.
Read the Governance and Release docs
Read the Governance and Trust feature page
5. Manage integrations and admin controls
The lifecycle needs operating surfaces around it. Projects and warehouse connections give metric work a scoped place to live. Team access, billing, security, integrations, audit, and approval workflow settings decide who can administer the organization, which connectors are release-ready, and which reviewers can participate without receiving broad admin access.
Integrations should be read as lifecycle connectors, not as a replacement for the systems teams already run. Warehouses provide catalog and validation context. dbt YAML export supports local semantic-layer handoff. GitHub and Jira support release handoff through organization-scoped token connectors. Identity, notifications, approval email delivery, and approval webhooks help the right people and systems react to governed changes.
Read the Integrations and Admin docs
6. Monitor trust signals
Trust is not a single approval event. A governed metric should continue to show signals that help readers decide whether it is safe for the current decision. Useful trust signals include lifecycle state, owner, governance tier, approval status, validation recency, release version, managed variant relationships, deprecation cues, and curated Reasoning Trail notes.
These signals are especially important for AI agents. An agent should not treat a draft, deprecated, unverified, or disputed metric the same way it treats a released metric with current validation evidence and clear owner context. The public docs describe those signals at the product and API level so readers understand how lifecycle context should shape downstream decisions.
Read the Reasoning Trail concept
7. Serve context through the API
Once a metric is governed, external consumers need a stable way to read the context. The public v1 API exposes read-only metric discovery, metric detail, and an agent-facing contract envelope. That contract layer is the technical interface for AI agents, BI tools, CI workflows, and internal applications that need the approved definition, owner, lifecycle state, version, validation status, and curated context before they act.
The API is downstream of the lifecycle. It should not replace governance, validation, or release review. It makes their output consumable. A useful integration first discovers candidate metrics, selects the right metric, fetches the detail or contract response, and respects lifecycle caveats rather than assuming every matching metric name is authoritative.
Where to go next
Start with Getting Started when you are proving one high-value metric. Read The Context Layer when you want the conceptual model behind Metric Lifecycle Management. Use the Metrics Contract API documentation when an AI agent or downstream workflow needs the exact public contract shape for one governed metric.