You don't need YAML to define your metrics

Every semantic layer tool on the market starts the same way: open a config file, define your metrics, map the joins, deploy the model. Cube and dbt use YAML, Looker uses its own LookML, but they all assume you have someone on the team who can write and maintain these definitions. For most startups, that assumption is wrong.

The YAML tax

Writing metric definitions in YAML isn't hard if you know SQL and understand the schema. The problem is maintenance. Every time a column is renamed, a table is added, or a business definition changes, someone has to update the YAML. Miss one, and your metrics silently break.

# cube.js metric definition
cubes:
  - name: orders
    sql_table: public.orders
    measures:
      - name: revenue
        sql: amount
        type: sum
        filters:
          - sql: "{CUBE}.status = 'completed'"
    dimensions:
      - name: created_at
        sql: created_at
        type: time

This is fine for one metric. Now multiply it across 50 tables, hundreds of columns, and dozens of relationships. You're not defining metrics anymore. You're maintaining a parallel model of your entire database. That's a full-time job.

Who this actually works for

YAML-based semantic layers work well when you have:

• A data team of 3+ people who own the definitions
• A mature warehouse with stable schemas
• Multiple downstream consumers (dashboards, notebooks, APIs) that need identical metrics
• The discipline to treat your semantic layer as a codebase, with PRs, reviews, and CI

If you have all four, a hand-built semantic layer is a genuine competitive advantage. But most teams under 50 people have zero of these.

The real question

The goal of a semantic layer is consistent metrics. When your CEO asks "what's our revenue?" and your ops lead asks the same question, they should get the same number. YAML is one way to achieve that. It's not the only way.

What if you could get the same consistency without writing a single line of config?

Auto-generated metric definitions

Contextflo reads your database schema, your application source code, and your docs, and auto-generates table descriptions, column meanings, relationships, and metric definitions. You review them, tweak anything that's off, and you're done. The AI uses these definitions every time someone asks a question, so "revenue" always means the same thing.

The definitions live in Contextflo and are served to Claude (or any LLM) as context with every query. No YAML files to version, no deployment pipeline to run. And no structural drift between your definitions and your schema, because they are generated from the schema, source code, and docs directly. Business-meaning changes, like the CFO redefining "revenue," still need a human to update the definition, but you are not also chasing every column rename by hand.

What you lose (and what you don't)

Be honest about the real tradeoff, and it isn't edge-case aggregation logic (you can still add that by hand). It's the git-based workflow: version control, pull-request review, and CI on every metric change. If that governance is a hard requirement for you, a YAML layer is the right tool and you should keep it.

What Contextflo gives you instead is a lighter loop: definitions are auto-generated from your schema, source code, and docs, and you review and approve them before they take effect. Every change to a definition is logged, so you still have an audit trail of who changed what, even without a git history. You can still define the complex cases a YAML layer is good at (custom aggregation logic, time-zone handling) by adding your own metric definitions where the auto-generation doesn't go deep enough.

What you don't lose is consistency. The whole point, making sure everyone gets the same answer, works the same way whether the definitions were written by an analytics engineer or generated and then refined by you.

For most teams the trade is clear: auto-generated definitions cover most of what you need, and the rest can be handled as you encounter edge cases. No upfront YAML project required.

Try it

Connect your database to Contextflo, let it generate your metric definitions, and start asking questions. If you're spending time writing YAML instead of getting answers, you're solving the wrong problem.