4.8/5
Home

Integrations

Plug Count neatly into your existing data infrastructure

For data teams

Collaborative, AI-driven data exploration and modelling

For product & growth

Faster access to the answers which matter

For leaders

Turning data into an engine of improvement

Pricing

Latest post

Meet the new Count Agent

Meet the new Count Agent

Docs

Guides, references, and API docs

Blog

Opinions, analysis, and the occasional uncomfortable truth about data.

Webinars

Join our experts for deep dives into data analytics and business intelligence

Gallery

Browse ready-to-use canvas templates and try them instantly

Sign in

Where to begin?

Start for free

Spin up a canvas and explore your data — a couple of clicks, no card.

Book a demo

See it live. Bring your questions — we’ll bring the answers.

Still not sure?

Send us a note — we’ll point you the right way.


Data to decisions, faster.

Compare

  • Count vs BI
  • Count vs Notebooks
  • Count vs Chatbots
  • Count vs Hex
  • Count vs Looker
  • Count vs Tableau
  • Count vs Thoughtspot

Learn

  • Blog
  • Webinars
  • SQL tutorials

Legal & security

  • Privacy Policy
  • Terms of Use
  • Cookies Policy
  • Trust Center
  • Security

Social

  • LinkedIn →
  • YouTube →
  • X →

Start with the hard question.

Ask Count anything — we’ll take you straight into a canvas.

Opens sign-up with your prompt ready for Count.

© 2026 Count Technologies Ltd. All rights reserved.

Careers →Book a Demo →
count
← Back to blog home
March 31, 2026

Semantic interoperability

Written by Oliver Hughes

Semantic layerAI analyticsAutomation

Oliver Hughes explains how Count auto-converts LookML, Snowflake, and OSI models into a unified semantic layer, eliminating rewrites and keeping metrics in sync.

TL;DR Today we’ve launched automatic conversion of LookML, Snowflake, and OSI models into Count Metrics, making it easy to use or migrate your existing semantic layer in Count without rewriting it.

A year ago we introduced Count Metrics: our own take on a semantic layer. We wrote at the time about our decisions and process behind creating our own format in a world, and as we’ve gone on to build Count’s AI agent, we and our customers have seen the benefit of the increased metadata and context available, and the power of catalog-backed compute-layer to accelerate agent query iteration.

In that time we’ve also helped numerous customers convert their existing LookML, Snowflake, and other data models into Count Metrics. Sometimes focusing on small, underserved parts of the business, but often complete soup-to-nuts conversions.

We learnt two things along the way:

  • No one really wants to maintain more than one semantic layer.
  • It’s hard for businesses to justify the effort to convert their model into a different format and run the gauntlet of breaking everything.

At the same time we’ve watched the introduction of the Open Semantic Interchange (OSI) specification and seen the lukewarm reaction for the very same reasons.

We all know that XKCD comic about open standards. Yes, that one.

There's a deeper problem underneath all of this. Teams are being asked to bet on a format at exactly the moment nobody agrees on what the right one is, and as AI agents become the primary consumers of semantic context, that decision feels more consequential than ever. The business logic and metric definitions your team has sweated over are genuinely valuable. They shouldn't be trapped by whichever tool happened to produce them.

If people don’t want to maintain multiple formats or risk conversions themselves why don't we meet them in the middle?

Today we’re releasing automatic conversion of LookML, Snowflake and OSI semantic models. Upload them into a Count Metrics catalog and we'll convert them instantly, covering nearly all syntax and functionality in those formats - with the option to extend definitions using Count-specific features.

You can do a one-time import, or keep your original files as the source of truth with automatic conversion: Count stays in sync as they change, dynamically regenerating your catalog files. This works especially well when your definitions live in a GitHub repo.

We're also one of the the first tools to support OSI v0.1.1. We believe interoperability is the answer, and that a common language makes it easier to get there. The ecosystem is still catching up, but we're proud to be early adopters, and we'll continue to work closely with OSI as it evolves.

How it works

Automatic conversion: When LookML, Snowflake YAML, or OSI files are present in a catalog, they're converted on-the-fly into Count views and datasets. Generated files are read-only and tagged with their source. If a file changes upstream, the generated output updates automatically. You always know what came from where. If you do want to migrate, you can do a one-time conversion that produces first-party Count YAML files you maintain directly.

Extending without modifying: You can extend any third-party definition with Count-specific properties, such as adding fields, labels, caching rules, AI context, without touching the original file. This is useful when you want Count to behave slightly differently from your canonical model for a particular team or use case, while keeping the upstream file clean.

What's supported: Across all three formats we convert the things that matter most: views and datasets, dimensions and measures, joins and relationships, derived tables, and time fields with timeframes. Where we can't convert something, such as complex Liquid templating in LookML, non-ANSI SQL dialects in OSI, we preserve it as a commented stub with an explanation, so nothing is silently dropped.

This makes it easy to try Count on existing data models, or subset/extend them to support new classes of users who are not well served at present.

You can find out more in our docs here: https://learn.count.co/docs/third-party-file-support

Over the coming months we’ll be adding support for other common formats.

Our goal is simple: to make Count as interoperable with existing data tools as possible. We believe this is the future, where semantic context is portable, flexible, and not locked into any one system.