dbt 1.12 gives agents a more portable semantic layer—but the migration is not format-neutral

dbt 1.12 makes two changes that matter to teams using a semantic layer to ground analytics agents: it can ingest Apache Ossie semantic definitions, and it introduces a new native Semantic Layer YAML shape. Both improve portability, but neither is a drop-in migration.

Two representations now enter the manifest

The release guide says projects can place Ossie-format JSON files in an osi/ directory, after which dbt parses them into the manifest alongside native dbt semantic models. Support is explicitly limited to Ossie 0.1.0 and 0.1.1; other versions raise a parse error. At parse time, dbt also writes an osi_document.json artifact next to semantic_manifest.json.

That gives agent builders a useful interchange boundary: semantic definitions can move through an open format while dbt still emits its own semantic artifact. But “alongside” is the important word. During rollout, compare both outputs rather than assuming the Ossie document and native manifest express every metric, entity and dimension identically.

The native YAML shape also changes

In the new specification, semantic_model moves inside each model, entities and dimensions move to column definitions, and measures become simple metrics. The older type_params nesting is deprecated, with its fields promoted into metric definitions.

Those changes make semantic metadata sit closer to the physical model and columns it describes. They also change the files and paths that downstream indexing, lineage and agent-context pipelines may parse. A successful dbt run is therefore necessary but insufficient evidence that an agent is seeing the same business definitions.

Patch releases matter to the semantic contract

The current GitHub release is dbt 1.12.6, published October 14. Its release notes include a fix for cumulative metrics using an input_metric plus a top-level window, which had incorrectly failed with a legacy type_params error. The patch also adds semantic_manifest.json to artifacts uploaded through the artifacts-ingest API.

That pairing is operationally significant: a metric can parse correctly locally yet remain absent from an external consumer if the expected artifact is not uploaded. Teams should test the full path from source YAML through generated artifacts to the agent or BI service that consumes them.

A safer rollout

Run the old and new semantic definitions against the same representative questions. Diff semantic_manifest.json and osi_document.json; verify entity keys, dimensions, metric windows and generated SQL; then check that the artifact-ingest path delivers the same definitions downstream.

The guide also labels dbt’s opt-in Rust v2 parser beta and warns that its manifest can differ from the Python parser in edge cases. Do not combine a parser migration, YAML rewrite and Ossie adoption in one unobservable cutover. Change one boundary at a time, retain the generated artifacts, and keep the Python parser as the documented fallback until agent answers and compiled queries match.