YAML Semantic Layers Are Not Enough

The Problem with YAML

Great - you have a semantic layer. Now your intern/agent/ceo wants to ask a question. It's not quite answered in the layer - you're close, but they want some new fields. It's time to pull out SQL. You run the query, give the answer, and file a backlog ticker to extend the semantic layer.

This is what ultimately drives teams back to SQL - if you can't get the entire job done, then what's the point? If you just need to fall back to SQL, why not just use SQL all the time?

YAML based semantic layers add this friction to every action. Someone discovers, explores, and develops in SQL - then they have to design and hand off that context to YAML. THen someone consumes it, provides feedback, and the cycle repeats. It's slow, it's error-prone, and it doesn't scale.

What's better

If your semantic layer is a first-class language, you can do all of this in one place. You can explore, prototype, and iterate in the same language you use to deliver production results. You can share snippets, functions, and logic between humans and agents. You can build up a library of common patterns that everyone can use. You don't need to go back to SQL every time - (though escape hatches are good to have!).

We believe that YAML semantic layers only cover a fraction of the data lifecycle today. To truly accelerate analytics and deliver on their value proposition, they must cover 80% of more.

That's why we built Trilogy - a full-featured, expressive language that is easy to learn, gets out of your way, and is powerful enough to extend and evolve with your needs. You don't need to go back to SQL - and that makes all the difference.