Microsoft and Google back Apache Ossie, the open spec for portable semantic models

For GCC organisations running Power BI on Snowflake, Databricks or BigQuery, the semantic layer is where lock-in lives. It is also where the value is. Years of metric logic, what revenue means, which joins and filters apply, sits trapped in a BI tool's proprietary format. Rebuilding it is the largest hidden switching cost in any platform move. It is a common reason BI migrations slip. With Microsoft and Google on board, that logic becomes a portable, versioned asset. Define it once in Ossie YAML. Convert to Power BI structures via TMDL, to Snowflake Semantic Views, or to dbt semantic models. Procurement conversations shift when the buyer can export the semantics on the way out. AI programmes get real when every agent reads the same definition of revenue.

The engineering here is substantive, not a press release. The core specification is a YAML and JSON schema, currently at 0.2.0.dev0. The last fixed point is 0.1.1, dated 2025-12-11. It covers datasets, relationships, fields and metrics. Its expression object carries multiple dialects per definition. The enum today lists ANSI_SQL, SNOWFLAKE, MDX, TABLEAU, DATABRICKS, MAQL (GoodData), BIGQUERY and THOUGHTSPOT. Microsoft has pushed a DAX addition through the ASF process alongside the Power BI converter (Snowflake engineering post). The converters guide makes the arithmetic clear. N vendors need 2N converters in a hub-and-spoke design, not N(N-1) point-to-point translators. In the repository, every construct carries an ai_context block (instructions, synonyms, examples) intended for agent grounding.

Where most teams will get it wrong is treating a clean export as a working migration. A metric can survive conversion syntactically and still compute differently. The destination engine interprets joins, NULLs and time calculations its own way. This bites hardest on DAX, where time-intelligence functions, calculation groups and context transitions do not map cleanly onto ANSI SQL. Governance is the second trap. Row-level security, access policies and certification status are not first-class elements of the spec. They sit in the roadmap's future Governance, Identity and Validation work (per the project roadmap). You must re-apply them per platform after every conversion. Lock-in does not disappear. It shifts into execution engine behaviour and into custom_extensions, where vendor-specific metadata increasingly lives.

How Azrty would approach it: hold the Ossie YAML in Git as the source of truth for business definitions. Change it through pull requests, like any other code. Validate every model in CI using the repository's tooling: JSON Schema, unique names, reference integrity, SQL syntax. Pin production pipelines to 0.1.1 semantics while 0.2 remains a mutable draft. Keep vendor-specific settings in custom_extensions so round-trips lose nothing. Run golden-number tests on every KPI after each conversion. A metric worth porting looks like this, with the vendor dialect preferred and ANSI_SQL as the fallback:

metrics:
  - name: total_revenue
    description: Total revenue across all orders
    datatype: Decimal
    ai_context:
      synonyms: ["total sales", "revenue", "net sales"]
    expression:
      dialects:
        - dialect: DATABRICKS
          expression: SUM(orders.amount)
        - dialect: ANSI_SQL
          expression: SUM(orders.amount)

On that foundation, the agents we build in AI engineering and the platforms we run in AI infrastructure get one governed answer per business term. That is what agentic analytics needs. Inconsistent definitions quietly destroy it. The opportunity in the UAE and GCC is real. Regional enterprises run unusual multi-vendor stacks across BI and cloud. Portable semantics cut migration risk and the cost of giving AI systems trustworthy business context. The risk is equally real. Teams will adopt the format, skip number-level validation and governance re-declaration, then find the discrepancy in a board report.