TL;DR. Apache Polaris 1.8.0 makes the semantic model a catalog entity. The model document, stored in the Apache Ossie format, now lives inside the catalog beside the tables it describes, guarded by its own privilege class with grants at model, namespace, and catalog scope. The same release rewires how authorization evaluates, binds internal tokens to a new claim, and corrects a Postgres index that existing deployments must recreate by hand, because Polaris does not run schema migrations for you. The mechanics are well documented. The decision the release actually creates, who may define meaning in your catalog, arrives without a checklist.
On September 28, 2026, Apache Polaris shipped 1.8.0, and the headline feature closes a loop that opened in July. When Open Semantic Interchange entered the Apache Incubator as Apache Ossie, the project's announcement listed integration with Apache Polaris, "so that semantic models are discoverable directly from the catalog," among the goals the community might pursue together. Two months later the goal is shipped code: Polaris now stores Ossie semantic models as first-class catalog entities, and 1.8.0 adds a dedicated privilege model on top of them.
Dremio published a thorough upgrade runbook within a day, and the official release notes cover the operational surface well. What the early coverage skims is the part that matters for anyone putting AI agents on top of a catalog: what it changes that semantic models now answer to the same authorization system as tables, and where exactly that authorization stops.
A semantic model is now something you grant access to
The entity itself landed in August, in PR #4961. A Polaris semantic model stores the Ossie document, the spec version plus the model content, in its entity properties, following the same pattern Polaris already uses for policies. Models are scoped to a namespace. At write time, Polaris resolves every dataset.source reference in the document against the catalog and rejects a model that points at tables the catalog does not know. Updates go through optimistic concurrency on the entity version. The PR's review thread even captures the naming transition mid-flight: it was opened against "OSI semantic models" and renamed during review, because OSI had just become Ossie.
What 1.8.0 adds is the authorization half. Listing, creating, reading, updating, and dropping a semantic model are now five dedicated privileges, grantable on one model, on a namespace, or across the catalog. Grant management is separated from editing, a distinction Dremio's guide calls out as the useful one: a team can hold the right to change the revenue model without the right to delegate access to it. The API behavior got tightened alongside, down to returning a 404 when a model disappears mid-deletion instead of failing opaquely.
The location is the point. Until now a semantic model lived wherever its producing tool kept it: a dbt project, a BI workspace, a YAML file in a repository. The catalog could govern what a table is, while the document saying what the table means answered to a different system with different permissions, often none. Write-time source resolution plus shared grants puts the definition and the data under one authorization regime. When Ossie entered the incubator we argued that the spec standardizes definitions and leaves trust out: confidence, lineage, freshness, and provenance appear nowhere in it. A catalog that holds the model and controls who may change it supplies one of those missing properties, an owner-controlled write path. That is a real piece of the trust story, delivered by the catalog rather than the spec.
The grant is checked at the API, and only there
Follow a model through one working day, though, and the boundary of the new privilege class shows itself. A grant is evaluated when a request crosses the catalog API. An agent holding the read privilege loads the revenue model over MCP, the check passes, and from that moment the agent holds the definitions. The SQL it writes next runs on a query engine the catalog does not mediate. Whether that query computes the metric the way the model defines it is invisible from the catalog's vantage; nothing at this altitude compares an execution plan against a semantic document. The shape is familiar from credential vending on the Iceberg REST catalog: the catalog decides access at the moment of the handshake, and the data path afterward belongs to other systems.
The 1.8.0 privilege model, drawn to scale of its authority. Grants hold on the catalog edge. The definitions keep working past it.
The definitions themselves also still underdetermine results. The first genuine dispute inside the Ossie project is over whether the spec should standardize how a metric evaluates rather than only what it is, and that question remains open. Until it lands, two consumers with the same read grant can hold identical documents and return different numbers for the same metric. So the accurate reading of 1.8.0 is narrower than "governed semantics": it governs who may see and change meaning, at the catalog. What gets executed from that meaning stays ungoverned by anything in this release.
That narrower thing still matters. An ungoverned definitions store fails in a specific way: whoever can reach it can redefine revenue, and the consumers downstream apply the new definition without anyone having decided that. Polaris closing that path at the catalog is the right first move, and the write side of the enforcement is complete in a way the read side cannot be.
The breaking changes concentrate in authorization
Three of the four breaking changes live in auth infrastructure, which tells you where the engineering effort went.
First, evaluation. A request carrying several authorization intents is now evaluated one intent at a time, and custom authorizers must implement the new per-intent interface. Authorization inputs also no longer include the synthetic ROOT container, so a custom authorizer or OPA policy that matched on it now matches nothing. If you run OPA, the release notes and Dremio agree on the consequence: retest the policy set, and expect separate OPA queries per intent where one combined query used to arrive.
Second, tokens. Internal JWTs are now bound to principal secret generation through a polaris-cv claim. Tokens minted before the upgrade stay valid as bearer tokens until they expire, but they no longer work as subject tokens in token exchange. During a rolling upgrade that difference surfaces as intermittent exchange failures, old nodes minting unexchangeable tokens beside new ones, until the last pre-1.8 node drains.
Third, commit semantics. A stale concurrent table commit now returns a retryable 409 where it used to return a fatal 400, and a commit whose outcome the server cannot determine maps to 500, a status that means the commit may have been applied even though the client never got a definitive answer. Retry logic keyed on status codes should be re-read against both: the 409 is an invitation to retry that clients used to treat as a dead end, and the 500 is a warning against blind retry that clients used to treat as safe.
The fourth change is pagination. Servers can now enforce a maximum on client-requested list page sizes, and a capped response is truncated with a continuation token attached. A client that asks for ten thousand entries and has always received them in one page will keep getting a successful response, now with a token it has never had a reason to follow. Code that treats the first page as the whole listing loses rows without an error.
The catalog's own database is still your job
Polaris persists its metadata through a JDBC backend, typically PostgreSQL, and 1.8.0 is a reminder that this database is operated, not managed for you. The release corrects the idx_locations index to lead with (realm_id, catalog_id, location_without_scheme) instead of parent_id. Polaris ships no automated schema migrations, so on an existing deployment the corrected index arrives only if you recreate it yourself. CockroachDB deployments have it one step worse: three indexes the schema should have carried all along, idx_grants_realm_grantee, idx_grants_realm_securable, and idx_entities_catalog_id_id, must be created manually. Fresh installs meet the same philosophy from the other side, because the JDBC backend no longer auto-creates its schema: CREATE SCHEMA polaris_schema; is now your statement to run before bootstrap. In the same area, 1.8.0 fixes a lost-create bug under SERIALIZABLE isolation on the JDBC backend, worth knowing if you ever saw an entity vanish under concurrent writes.
Dremio's runbook frames the index work correctly: schedule it as a database change, with review and a window, never as an application startup side effect. On a catalog of production size that means CREATE INDEX CONCURRENTLY, the usual watch for an invalid index if the build fails, and a DROP of the old index only after the new one is in place. A wrong index never errors; it just makes every location lookup quietly worse, which puts it in the same class as the defaults that changed in OpenMetadata 2.0: the upgrade completes green, and the difference surfaces later, as load.
What to decide before upgrade day
The mechanical sequence orders itself: retest custom authorizers and OPA policies against per-intent evaluation first, schedule the index recreation with the upgrade rather than after the slowdown, drain pre-1.8 nodes before trusting token exchange, and re-read client retry handling for the new 409 and 500 semantics.
The non-mechanical item is the one the runbooks do not carry. After the upgrade, your catalog can hold semantic models, and the privilege class exists whether or not you assign it deliberately. The first team to create a model in a loosely governed namespace sets your de facto policy on who defines meaning. Deciding the grant structure before the first model exists is cheap. Unwinding a catalog full of models nobody explicitly authorized is the expensive version of the same decision.
Where Datapace fits
Polaris 1.8.0 governs semantic models at the catalog: who may define, change, and read meaning. Datapace is building the context layer between your databases and your AI: resolved meaning validated by the people who own the data, the workload evidence beside it (cost, performance, usage and freshness, lineage), and a policy gate over what an agent may do and access, served over MCP. If your agents read definitions from a catalog and execute somewhere else, the span between those two points is the conversation: book a call.
Sources
- Apache Polaris, 1.8.0 release notes, September 28, 2026 (semantic model privileges and scopes, per-intent authorization, ROOT removal, polaris-cv claim, idx_locations correction, CockroachDB indexes, manual schema creation).
- Apache Polaris, GitHub release apache-polaris-1.8.0 (PR index: #5492 semantic model privileges, #5499 deletion 404, #5194 per-intent authorization, #5053 JWT binding, #5138 commit status codes, #5282 pagination cap, #5361 CockroachDB indexes, #5094 SERIALIZABLE lost-create).
- Apache Polaris, PR #4961: semantic-model core entity and CRUD, merged August 11, 2026 (Ossie document storage, namespace scoping, write-time dataset.source resolution, optimistic concurrency, rename from OSI to Ossie during review).
- Alex Merced, Dremio, Apache Polaris 1.8.0: What's New, Breaking Changes, and Upgrade Guide, September 29, 2026 (grant management separated from editing, mixed-version token exchange failures, index change SQL, pagination truncation behavior).
- Apache Ossie, Apache Ossie (Incubating): The New Name for Open Semantic Interchange, July 10, 2026 (Polaris integration named on the roadmap, more than 50 organizations).