> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/release-notes/june-2026.md). # June 2026 ### DataOS 2.0 is now live! Build Data Products on your engine, govern semantics in the product, and serve the same definition to people, BI tools, and AI agents. | | | | ---------------- | ---------------------- | | **Release** | DataOS 2.0 | | **Release date** | `June 2026` | | **Status** | `General Availability` | | **Upgrade from** | DataOS 1.0 | *** DataOS 2.0 changes how you spend your day. Less time wiring tools together, chasing broken pipelines, and asking around for which table to trust. More time shipping data that people, applications, and AI agents actually use. This release is a collaborative effort across the whole team, built to reflect the feedback we heard, the features you asked for, a better experience end to end, and the core business needs our platform now enables. You write the logic. DataOS handles the contracts, lineage, access, and activation through the GUI, CLI, or APIs. Open a Data Product and scroll the redesigned detail page: freshness, quality, lineage, and connection options that used to sit in separate tabs are on one page. Governance that travels with the product, a catalog you can trust before you query, and one definition that reaches BI, apps, and agents without rewiring each time. All this while we heard patiently, and this is our effort to deliver with confidence. The fastest way to feel the difference is to ship something. You can have a working Data Product running against your own engine in a single sitting: [Build your first Data Product](/build/get-started/build-your-first-data-product.md) *** ### The shift behind 2.0 For a decade the goal was to pull everything into one warehouse and let people self-serve. That worked until AI agents started returning confident, wrong answers. They had the tables but not the context a human analyst carries: which table is canonical, what "revenue" means, when the quarter ends. DataOS 2.0 treats the **Data Product as the atomic unit**, kept above the engine instead of locked inside it. Contract, semantics, lineage, and quality travel with the product. You build context once; every consumer, including agents, reuses it. Your work follows the path a Data Product takes: * **Discover.** Browse the catalog, profile data, and pull in what is missing before you commit to building. * **Produce.** Write transformations in SQL or Python, enforce the contract in-band, and define the semantic layer once. * **Consume.** Serve the same product to BI tools, applications, notebooks, and AI agents through the protocol that fits each one. Governance, lineage, and observability apply across all three. They are properties of the stack, not separate projects. {% hint style="info" %} Want the full argument behind this design? Read [Data Products: The Essential Context for Enterprise AI](https://moderndata101.substack.com/p/data-products-the-essential-context). {% endhint %} *** ### Start where you are Skip to the parts of this release that match what you do. | You are | Start with | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | A data engineer building products | [Build on your engine](#build-on-your-engine), [See what a change breaks before you ship it](#see-what-a-change-breaks-before-you-ship-it) | | A data analyst or consumer | [Trust data before you query it](#trust-data-before-you-query-it), [Serve it to BI and apps](#serve-it-to-bi-and-apps) | | Working with AI agents | [Let AI query your data safely](#let-ai-query-your-data-safely) | | A CTO or platform owner | [The shift behind 2.0](#the-shift-behind-20), [Provision a tenant without tickets](#provision-a-tenant-without-tickets), [Release details](#release-details) | | A program manager or steward | [Governance and access](#governance-and-access), [Known limitations](#known-limitations) | | Running data pipelines | [Move data reliably](#move-data-reliably) | Every section below has a **What changed** drawer at the end. Open it for the full list of new capabilities, improvements, and fixes in that area. *** ### Build on your engine You don't move your data to use DataOS, and you don't learn a new runtime. Point it at Snowflake, BigQuery, Databricks, or Postgres, or use the DataOS Lakehouse with Spark or Trino. Write your transformations in SQL or Python, run them where the data already sits, and build your first Data Product the same afternoon. No migration, no rip-and-replace. The `behavior` key is the canonical way to say what a dimension or measure means: categorical vs identifier vs ordinal for dimensions; simple, flow, stock, ratio, or derived for measures. Those annotations travel with the product so people and agents interpret the numbers the same way. A few specifics that matter once you start: * **Snowflake Semantic View import.** Run `vulcan import_semantic_view`. Vulcan converts existing Snowflake semantic objects (tables, dimensions, facts, metrics, relationships) into Vulcan-compatible YAML. You do not rebuild the layer from scratch. * **camelCase in `config.yaml`.** Write `displayName` or `display_name`. Both work; existing projects stay compatible. * **Trino deployment options.** External (your Starburst or self-managed coordinator), Dedicated (Vulcan provisions the cluster), or Minerva (managed DataOS Trino). All three use `connection.type: trino`. * **Spark UI.** Monitor running Spark sessions from the Data Product page during plan, run, and API phases. Live UI hits the driver; History UI hits the Spark History Server for completed jobs. * **Resource YAML alignment.** Git sync uses `secretId`, matching Nilus and other DataOS resources.
What changed in Build **New** * Data Policies in semantic models. Declare group-based policies that mask dimensions or apply row-level filters. Enforced at query time across GraphQL, SQL, and the Data Product Hub. * Plugin hook (`afterAuthorize` in `config.yaml`) to resolve identity groups from the request's security context before policy evaluation. * `behavior` key for dimensions (`categorical`, `identifier`, `bucketing`, `ordinal`) and measures (`simple`, `flow`, `stock`, `ratio`, `derived`) with associated attributes (`time_dimension`, `period_treatment`, `period_grain`, `numerator`, `denominator`, `measure_refs`, `is_additive`). * `vulcan import_semantic_view` command. Imports Snowflake Semantic Views (tables, dimensions, facts, metrics, relationships) into Vulcan semantic definitions. Primary key fields are auto-assigned `behavior.type: identifier`. * camelCase support in `config.yaml`. All keys accept either `snake_case` or `camelCase`. Fully backward compatible. * External Trino support. Connect to an existing Trino-compatible endpoint (Starburst, self-managed coordinator). * Dedicated Trino support. Vulcan provisions the Trino cluster and catalog configuration as part of deployment. `trino.overideCatalogConfig` appends per-catalog properties on top of the auto-generated depot configuration. * Spark UI access from the Data Product page. Live UI via driver peer-client service; History UI via the Spark History Server. **Improvements** * Resource YAML: `secretId` replaces `secret` for Git sync configuration, aligning with Nilus and other DataOS resource conventions. * Spark executor creation issue resolved. Executors now provision correctly during deployment.
*** ### See what a change breaks before you ship it Change one upstream column and three dashboards go wrong two weeks later. Lineage in 2.0 runs column to column, source to output. The **Assets** tab puts lineage and semantics in one place so you see upstream health without leaving the product page. Input tables show live source metadata and quality run history inline. The Activity tab adds a run trend graph, a navigable run list, and per-run error detail so you can trace what failed and when. View lineage FQN generation is corrected, and lineage for assets in the Inputs section is visible.
What changed in Assets and lineage **New** * Input tables on the Assets tab show live source metadata and quality run history. * Activity tab: run trend graph with navigable run list and per-run error and model evaluation detail. * Dedicated sub-pages for Data Dictionary, Data Quality, Plan/Version history, and Run activity. Each is accessible from quick-access links on the landing page. **Improvements** * Assets (Semantics and Metrics): view lineage FQN generation corrected. * Dataset lineage theming aligned with platform design system. * Assets → Relationships: padding above the table corrected. * Overview graph includes apps, products, and metrics for a fuller picture of the Data Product's ecosystem. **Fixes** * Lineage not visible for assets in the Inputs section. Now surfaced correctly. * Asset profile no longer shows NaN for text column most frequent values. * Dataset icons for Trino and other dialects render correctly in overview lineage.
*** ### Trust data before you query it Before you run a query, you need to know whether the data is safe. The Data Product listing is rebuilt around how consumers browse: card and list views, filters by domain, tag, owner, or quality state, and multi-scope search across Data Products, Perspectives, and Metrics in one query. The detail page is a single scroll. A hero section, quick-KPI bar, and sticky table of contents put freshness, quality, and ownership above the fold. Sections render when data exists and stay out of the way when they do not. Dataset browsing works at global level, then narrows to source type, database, and schema without losing context.
What changed in Discover **New** * Data Product listing: card and list views, contextual filter panel (domain, tag, owner, quality), multi-scope search across Data Products, Perspectives, and Metrics. * Data Product detail page rebuilt as a single-page experience: hero section, quick-KPI bar, sticky table of contents, stacked sections with graceful empty states. * Dedicated sub-pages: Data Dictionary (all assets with columns, tags, quality, dependencies, lineage), Data Quality (summary scores, freshness, quality trend, rule breakdown), Plan/Version history (per-plan change history with additions, removals, modifications, downstream impact, backfill indicators), and Run activity. * Product-scoped listing pages for Applications, Perspectives, and Metrics. * Enhanced dataset traversing: browse and search at global, source-type, database, and schema levels. **Improvements** * Activity and Connect tabs show data inline in the Hub. Check freshness and consumption without leaving the page. * Data product listing: Top users removed from "How it is being used"; standalone Perspectives section removed from landing (kept in Usage). * Activation breadcrumbs simplified. * Data product details: graceful behaviour when no semantic models exist. **Fixes** * Post data product rename, the updated name now reflects on the UI. * Deleted data products no longer remain visible in the listing. * Owner mapping now consistent when user is absent from Heimdall. * Tags not displayed on listing pages (Products, Perspectives, Assets, Metrics). Fixed. * Latest run history now visible as expected. * Plans (version history) back button now returns to the DP landing page instead of the listing. * Metrics not visible across tenants when names are identical. Cross-tenant name conflict resolved. * Column defined as date type but displayed as string in column metadata. Fixed. * UI now accepts valid entity names as per DataOS regex.
*** ### Serve it to BI and apps Once a Data Product is published, the same definition should reach every consumer. In 2.0 it does, with less setup per tool. * **Power BI.** Advanced string filters work for report authoring. Documentation covers the path from Desktop to Power BI Service. * **Tableau Desktop.** Live connection to semantic models for building visualizations. Tableau Server and Online are on the roadmap. * **SDKs.** Application developers integrate through SDKs instead of hand-rolling API calls. The Postman Collection documents each endpoint: purpose, when to use it, required parameters, expected response. * **DB clients.** Browse objects and distinguish Semantic Models from Metrics, Measures from Dimensions. `information_schema.tables` exposes `TABLE_COMMENT` for that metadata. * **Studio.** Semantic SQL mode with a schema panel, query editor, and results panel. Metric Details Page lets you open any metric and query it with metric-specific field selection. Filtering supports multiple values and nesting. * **Workbench.** Cell duplication, resizable panel divider, column resizing in results, sequential row numbers, expand-on-click for large text values. The **Activation Hub** on the Data Product detail page collects connection pages for MCP, API, BI tools, and MySQL/DB clients in one place.
What changed in Consume and Activation **New** * Activation Hub on the Data Product detail page: dedicated connection pages for MCP, API (with Vulcan-native Postman collection download), BI tools (Power BI and Tableau connection packages), and MySQL/DB clients. * Power BI advanced string filters. Previous filter limitation on string data types removed. * Power BI report publishing guidance. Step-by-step documentation for moving reports from Desktop to Power BI Service. * Tableau Desktop support. Live connection to semantic models for building visualizations. * SDK support for programmatic integration with Data Products. * Enhanced Postman Collection: endpoint-level context including purpose, usage, required parameters, and expected response structure. * DB client metadata: distinguish Semantic Models vs. Metrics and Measures vs. Dimensions through `information_schema.tables TABLE_COMMENT`. * Studio: Workbench-like Semantic SQL mode with schema navigation panel, query editor, and results panel. * Studio: Metric Details Page. Open and query metrics directly with metric-specific field selection. * Studio: GraphQL merged into a single studio application as one of the modes. * Workbench: cell duplication, resizable divider between left and main panels, column resizing in query results, sequential row numbers, expand-on-click for large text values in cells. * Vulcan grants configured for UI consumption of query, perspective, and follower endpoints. **Improvements** * Studio: filtering rebuilt. Supports multiple values, nesting, and easier extensibility. * Studio: query status polling no longer capped at 60 iterations, supporting long-running queries. * Studio: full-screen mode. Results fill available height instead of a fixed-height container. * Studio: last column header no longer stretches to table end when there are few columns. * Workbench: smooth lazy-loading scroll without disruptive spinner interruptions. * Workbench: per-cell query execution guidance added. * Workbench: selected column names in multi-select now comma-separated. * Activation options with semantic dependencies are locked to prevent misconfiguration. * Activation breadcrumbs simplified at all levels. **Fixes** * Studio: incorrect payload for measure filter. * Studio: metric context, navigation, and granularity work as expected. * Studio: accelerated query time no longer shown as identical to non-accelerated. * Studio: deselected dimension/measure no longer remains highlighted. * Studio: Save as Perspective no longer stays disabled after a successful query in SQL mode. * Studio: unable to save perspective when query returns no results. Resolved. * Perspectives: visibility and load issues resolved (delay, missing listing, and special character impact fixed). * Perspectives: description formatting issues and missing "View More" for long content fixed. * Perspectives: visibility mismatch between listing and detail view corrected. * Perspectives: "Last Updated" timestamp no longer shows incorrect or stale dates. * Perspectives: back navigation from perspective no longer shows "Could Not Find Product" or generates incorrect URLs. * Workbench: no support for selective depot access. Resolved. * Workbench: self join no longer fails with cell reference on larger data. * Workbench: executes selected query in SQL editor instead of always running the first query. * Workbench: clicking JSON cells now opens JSON viewer/sidebar in query results. * Workbench: displays correct values when result column alias contains ".". * Workbench: full-screen behaviour corrected. * Workbench: zero schema access now shows appropriate empty state instead of broken UI. * Workbench: immediate tabular results rendering restored. **Known limitation** * Tableau support is currently limited to Tableau Desktop. Tableau Server and Online are on the roadmap.
*** ### Let AI query your data safely Pointing an LLM at a raw warehouse is how you get confident, wrong answers. In 2.0, Data Products reach agents through MCP as governed tools, not open tables. Every request is tenant-scoped: the agent only sees what the authenticated user can see. | Capability | What an agent can ask | | ------------------ | ---------------------------------------------------------------------------------------------------------------------- | | **Discover** | What Data Products do you have? What is in this one? Filter by domain, tag, or glossary term. | | **Trust** | Tell me about quality, lineage, and freshness. Is this column PII? Show me failing checks. | | **Query** | Show me revenue by region last quarter. Slice this metric by city. | | **Profile** | What does the distribution of this column look like? How many nulls? What are the min and max values? | | **Design** | Turn a use case into a validated design spec (measures, metrics, dimensions, contracts) through a guided conversation. | | **Scaffold** | Produce a complete project file manifest from a design spec, ready to fill in rather than write from scratch. | | **Quality checks** | Generate checks across all eight quality dimensions with SLOs and a gap analysis of what is missing. | | **Enrich** | Add descriptions, tags, and business terms so a product is documented and discoverable. | Retrieval is deterministic. The data comes from the Data Product API, not the LLM.
What changed in AI **New** * Works with any MCP-compatible assistant, including ChatGPT, Claude, Cursor, and LangChain agents. * Every request is tenant-scoped. An agent only ever sees what the authenticated user is entitled to see. * Plain-language query against live Data Products. No SQL required. * Catalog search by description, intent, domain, tag, or business term, not just exact name. * Lineage tracing to the column, upstream and downstream, for impact analysis. * Table profiling: column statistics, distributions, null counts, min/max before querying. * Quality and run history: check freshness, passing/failing checks, and last refresh time. * Design advisor: guided conversation (business context → data structure → activation) that produces a `data_product_plan.md` and a verified `vulcan plan`. * Scaffold generation: complete project file manifest from a design spec. * Quality-check suggestions across all eight ODPS quality dimensions with SLOs and gap analysis. * Metadata enrichment: add descriptions, tags, and business terms directly through the agent.
*** ### Governance and access Granting access used to mean a Bifrost trip or a privileged role. In 2.0, resource owners grant and revoke access from the Resource Catalog. Tenant admins get a dedicated application for invites, access, dataplane connections, and compute. Lakehouse access management is in Early Preview: read and write control at lakehouse, namespace, table, or view level. | Role | Scope | What it grants | | ---------------- | ---------- | --------------------------------------------------------------------------------------------------- | | `tenant_admin` | One tenant | Full access inside the tenant. Manages user roles, invites users, provisions compute. | | `data_admin` | One tenant | Manages data sources (depots, lake-houses, related access control). Aimed at a domain data steward. | | `data_developer` | One tenant | Builds Data Products. CLI access, deploy, monitor logs, set alerts, explore own Data Products. | | `data_consumer` | One tenant | Discover, explore, and consume Data Products they have access to. UI only. | Every allow/deny decision is logged with user, action, resource, decision, reason, and timestamp. You can query the trail from the UI.
What changed in Governance and access **New** * Tenant Admin application. Users with the `tenant_admin` role see this application in the left navigation. It surfaces Access Management, Data Plane, Compute, and the tenant creation Manifest. * Resource owner access management. Open a resource you own in the Resource Catalog, go to the Access tab, and grant or revoke permissions directly. No Bifrost trip required. * Lake House Access Management (Early Preview). Manage read and write permissions at the lakehouse, namespace, table, or view level. Access the application from the Resource Catalog or from the Manage Lakehouse button on the lake house details page. Permissions follow a downward hierarchy. * Centralized authorization audit trail. Every allow/deny decision is logged with user, action, resource, decision, reason, and timestamp, queryable from the UI. * Lakehouse application available for Tenant Admin and Data Admin to manage permissions across lakehouse entities. * One-time API token view-and-copy. Tokens are shown once on generation and never again. * Tenant invitation through email. Tenant admins invite by existing instance ID, by Modern AD ID, or by email. **Improvements** * Role dropdown closes automatically after a role is selected in Tenant and Instance Admin. * Ownership and assignment fields across listing pages correctly display and handle multiple users. **Fixes** * Role assignments refresh immediately after add or delete. No stale data. * Duplicate tenant names are validated in the UI instead of being silently accepted. * Switching tenants no longer causes incorrect redirects or errors on detail pages. * Lack of tenancy handling on internal/detail pages no longer causes incorrect redirection on tenant switch. * Typo in "Dataplane connection" label on Create Compute Instance corrected.
*** ### Provision a tenant without tickets Provisioning a secure environment used to mean weeks of back-and-forth with infrastructure. In 2.0, operators create tenants in a few clicks through Instance Admin. No Terraform for day-to-day tenant operations. Each tenant owns its Data Products, compute (mapped to a node pool in any supported cloud), and access control. A failure in one tenant cannot touch another. | Pattern | When to use it | | -------------------------------- | -------------------------------------------------------- | | Dev / Staging / Prod | Simple starting point. | | Isolation by line of business | Larger enterprises with separate domains and governance. | | Shared / cross-functional tenant | When two lines of business need to collaborate. | The **DataOS Health Page** is in Early Preview at `{your-instance-fqdn}/status`. Check whether the control plane and dataplanes are operational without opening a ticket.
What changed in Tenancy and operations **New** * UI-based tenant provisioning through Instance Admin. Create tenants without Terraform or operator intervention. * Tenant switcher in the top bar of the Hub. Switch between tenants when you belong to more than one. * CLI download information baked into the Hub UI. * DataOS Health Page (Early Preview). Check the operational status of the DataOS instance (control plane) and associated dataplanes at `{instance-fqdn}/status`. No administrator access required. **Improvements** * Transformations run on the warehouse; the API layer runs on the tenant's compute; the web app runs on the control plane. Duplicate compute eliminated.
*** ### Move data reliably Nilus ships with DataOS 2.0. You get control over metadata ingestion depth, MongoDB as a CDC destination, and a runtime hardened for restricted environments. Two callouts before upgrading: * **Lakehouse depots** require a user API token in the secret for authenticated reads and writes. * **Snowflake depots** carry the Snowflake role in the secret instead of the depot definition. Update existing depot and secret definitions before upgrading.
What changed in Nilus **New** * Deep and Shallow metadata ingestion modes. Control ingestion depth with a single `mode` key. `shallow` ingests metadata and lineage. `deep` ingests the full context: metadata, lineage, classification, profiling, and query usage. * MongoDB as a CDC destination. CDC pipelines can now write change streams into MongoDB. * Secret-based depot credentials. Snowflake depots carry the role in the secret; Lakehouse depots accept a user API token in the secret. * Data plane identity in pipeline metrics. Metrics now expose data plane name, network type, and type labels for fleet dashboard filtering. * Restricted-runtime support. Nilus runs under non-root, read-only-root-filesystem clusters using a persistent volume for staging and scratch space. **Improvements** * Nilus Manager APIs leaner: pipeline stats drop low-signal fields such as `total_records_processed`; list endpoints return a total count for accurate pagination. * Metadata ingestion SDK updated to `v1.12.6.21`. * Metadata usage and lineage pipelines complete faster. * Large, wide-table Lakehouse (Iceberg) loads tuned to avoid out-of-memory failures. New guidance on file size and persistent volumes in the Pipeline Optimization guide. * Nilus domain definitions now validate referenced resources at apply time via `resourceRefs`. * Default log level for CloudEvents Lakehouse and Quickwit workers changed to `ERROR`. **Fixes** * Kafka SASL\_SSL stream sources no longer fail due to a missing secret projection at runtime. * Usage pipelines no longer remain stuck in a running state after a metrics-push timeout. * Multi-line and multi-table SQL queries in `source_table` now publish lineage correctly. * Unnecessary warning noise suppressed for MongoDB sources. * Lakehouse metadata pipelines no longer emit access-denied warnings during successful ABFSS runs; repeated Iceberg REST 504 warnings resolved. * `relativePath` in Lakehouse depot configuration is now honored by the batch sink. * Deleting a Nilus domain no longer blocks deletion of its associated pipelines. * Metadata pipeline runs are now tenant-isolated: a run in one tenant no longer changes dataset visibility in another tenant using the same host. * CloudEvents payloads for pipeline executions corrected. * Hera query creation no longer fails with a 401 authentication error. * Lakehouse-depot workflows for the Data-Developer role no longer fail with 403 permission errors.
*** ### General fixes Cross-cutting fixes that did not belong in any single section.
What changed across the platform **New** * Resource Catalog: Access Control (Govern) tab on the Resource Details page for viewing, granting, and revoking access at the individual resource level. * Resource Catalog: Log search overhauled. Container selection, chronological ordering, expanded time windows (1m/5m/10m plus calendar time selection), and better use of available screen space in the Pod Logs viewer. **Improvements** * Resource Catalog: server-side pagination on Container group and Run history tabs. * Resource Catalog: Build tab shows complete build state details instead of partial information. * Resource Catalog: resource errors now direct users to the Build tab for root cause investigation. * Resource Catalog: Lakehouse Manager application accessible from Resource Catalog for lakehouse administrators. * Application icons updated to match latest design across Resource Catalog and Data Product BI sync tools. * Quickwit search logs API: flat/default response endpoint added. **Fixes** * Resource Catalog: service overview "updated at" info now populates on UI. * Resource Catalog: logs arranged in chronological order in workflow logs section. * Resource Catalog: resource app details now populate correctly. * Creating an API token with an existing name now shows a specific validation error message. * Dataset listing screen now displays datasets correctly. * Dataset schema now shown on the Datasets app UI. * Dataset Lineage tab no longer crashes for tables with unmapped tableType. * Dark theme disabled.
*** ### Known limitations * Tableau support is currently limited to Tableau Desktop. Tableau Server and Online are on the roadmap. * Perspectives are not editable. Create a new one to change columns or filters; this keeps consumer contracts stable. * Perspectives cannot span multiple Data Products in this release. Dedicated access policies for perspectives ship in the next release. * The Data Product MCP answers within one Data Product per query. Cross-product questions (for example, "list all PII columns across the system") are on the roadmap. * Lake House Access Management is in Early Preview and may still have usability or performance issues. * DataOS Health Page is in Early Preview and may change significantly in upcoming releases. * For large wide-table Lakehouse (Iceberg) loads in Nilus, attach a persistent volume and tune file size to avoid out-of-memory failures. See the Pipeline Optimization guide. * `` *** ### Release details | Area | Detail | | ----------------- | ---------------------------------------------------------------------------------- | | Supported engines | Snowflake, BigQuery, Databricks, Postgres, Trino, and Spark | | Supported clouds | AWS, Azure, GCP | | Open standards | Open Data Product Specification (ODPS), Open Semantic Interchange (tracking 0.1.1) | #### Component versions | Component | Version | Notes | | --------- | ------------ | ----------------------------------------------------------------------------------------- | | Vulcan | `0.228.1.26` | Includes Data Policies, `behavior` key, Snowflake Semantic View import, camelCase config. | | Nilus | `v2.0.21` | Deep/Shallow ingestion modes, MongoDB CDC destination, secret-based depot credentials. | | UI | `` | Data Product detail page redesign, Studio Semantic SQL mode, Activation Hub. | *** This is the first 2.0 release. We're keeping the door open: feedback, suggestions, and open questions are all welcome, so please reach out. *** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://v2.dataos.info/release-notes/june-2026.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.