> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dqlabs.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 1.3.3 Release Notes

> Prizm 1.3.3 release notes: Airflow pipeline observability, an ADLS connector, Issue and SLA modules, Microsoft Purview integration, AI guardrails, and vault-based secrets management.

<script type="application/ld+json">
  {`{
            "@context": "https://schema.org",
            "@type": "TechArticle",
            "headline": "1.3.3 Release Notes",
            "description": "Prizm 1.3.3 release notes: Airflow pipeline observability, an ADLS connector, Issue and SLA modules, Microsoft Purview integration, AI guardrails, and vault-based secrets management.",
            "url": "https://docs.dqlabs.ai/Release_Notes_v1.3.3",
            "publisher": {
              "@type": "Organization",
              "name": "DQLabs Inc",
              "logo": "https://media.brand.dev/332adc35-5bc4-4d2b-bf78-256aa4a5e414.svg"
            }
            }`}
</script>

<Note>
  This release consolidates work across pipeline observability, a new Azure Data Lake Storage connector, the new Issue and SLA modules, Microsoft Purview integration, AI guardrails, vault-based secrets management, and improvements across Metrics, DBT, Analytics, Governance, and platform navigation.
</Note>

# Features

This section contains the list of new features that are identified as a part of Prizm 1.0.

## Airflow Pipeline Observability

Prizm now connects directly to Apache Airflow to give data teams full visibility into pipeline health — not just the tables Airflow feeds, but the DAGs, tasks, and runs that produce them. Previously, a failure inside a pipeline was invisible to Prizm until it showed up as a downstream data quality problem. This release closes that gap with a dedicated Airflow connector, a pipeline catalog, lineage-aware root cause analysis, and a circuit breaker that can stop a pipeline before bad data propagates.

\[Screenshot: Airflow pipeline overview dashboard]

### Connecting Airflow to Prizm

The Airflow connector supports three connection methods, chosen based on what your environment allows. All three normalize to the same metadata model in Prizm — cataloging, lineage, and monitoring behave identically regardless of which one you pick.

**Method 1 — API-based connection**

1. Navigate to **Settings → Connect → Sources → Add Source → Airflow**.
2. Select **API** as the connection method.
3. Provide the Airflow REST API base URL and an authentication credential.
4. Click **Test Connection** — Prizm validates the credential and confirms it can reach the Airflow instance before saving.
5. Under **Run History**, set how much history to pull back on first sync (default: 7 days, toggle between "days" and "number of runs").

**Method 2 — Plugin-based connection**

1. Install the **Prizm Airflow Plugin** package into your Airflow instance's plugins directory.
2. The plugin hooks into the DAG execution lifecycle via Airflow's native event listeners — no polling required (push mode).
3. Set the environment variable `prizm_include_dag_source` to `true` if you want compiled DAG source code included (default is `false` — opt-in only).
4. Store the Prizm ingestion token using your environment/secrets backend rather than plain text, and rotate it periodically.
5. Confirm the connection shows **Active** under **Settings → Connect → Sources**.

**Method 3 — Agent/CLI-based connection**

1. Install the **Prizm Agent** on a host machine that has access to the Airflow CLI.
2. Configure the agent to run on a schedule; it invokes the Airflow CLI locally and pushes the collected metadata to the Prizm server for processing.
3. Confirm connectivity from the agent to both Airflow and Prizm using the agent's built-in connection check.

### Pipeline Catalog

Prizm builds and continuously reconciles a catalog of every in-scope DAG, task group, and task — pipeline identifiers, type, owner, tag mapping, schedule/frequency, last run time, and key metadata — designed to scale to very large Airflow deployments (100k+ workflows). The catalog initializes in two passes: the first job extracts pipeline metadata only, and the second backfills run history per your configured window. The catalog is queryable by domain, product, owner, and criticality once tags/semantics are mapped.

### Pipeline Monitoring

Alongside the plugin's push-based model (which needs no external monitoring), Prizm runs a polling monitor for API-based connections:

* Checks for new DAG/task activity every 15 minutes by default.
* Adapts refresh frequency automatically based on each pipeline's schedule — a pipeline with a freshness SLO under 15 minutes gets checked more often.
* Detects failures, tasks stuck or running too long, missed schedules, and silent failures (a pipeline that completes without error but produces no data).

### Lineage, Root Cause Analysis & GitHub Integration

1. Prizm extracts DAG- and task-level lineage from Airflow's REST API, building upstream/downstream relationships from task dependencies, `TriggerDagRunOperator`, `ExternalTaskSensor`, and Dataset scheduling.
2. When an alert fires, Prizm's investigation flow runs automatically: it walks the lineage graph upstream from the affected asset, identifies Airflow DAGs/Tasks in the upstream path as RCA candidates, pulls the last N runs for each candidate, and compares actual vs. expected schedule. If a failure or abnormal run is detected, Prizm pulls DAG run metadata, task instance states, and relevant failure logs.
3. **New in this release:** if a candidate DAG's source file lives in a connected GitHub repo, Prizm additionally fetches PRs merged to that file within the alert window, pulls the diff, and bundles the PR title/author/diff into the same LLM context as the alert details — producing a hypothesis such as *"Code change in PR #X may have caused this because…"*
4. The resulting hypothesis, evidence (lineage path, run timeline, log excerpts, and PR diff where applicable), and a confidence ranking are shown directly in the alert's investigation panel.

To enable the GitHub correlation step: connect your GitHub App under **Settings → Connect → Integrations → GitHub**, and grant read access to the repositories containing your DAG files.

### Blast Radius / Downstream Impact Analysis

Every incident view now includes an **Impact** tab showing which downstream data products, reports, and owners are affected — mapped by domain/product/owner, not just by pipeline name.

### Prizm Circuit Breaker — DQ Gates

Airflow DAGs can call out to Prizm at each medallion layer to validate the DQ score of an asset before continuing execution.

**Pre-requisites**

* In Prizm: Airflow connection configured, asset catalog synchronized, DQ Scores available, Circuit Breaker enabled.
* In Airflow: DQLabs Airflow package installed, DQLabs Circuit Breaker Operator configured, Prizm credentials configured.

**Setup steps**

1. **Step 1** — Configure the Prizm connection in Airflow.
2. **Step 2** — Install the DQLabs Circuit Breaker package.
3. **Step 3** — Add a pre-pipeline DQ gate task that validates the source asset's DQ Score before ingestion begins.
4. **Step 4** — Add the ingestion task, configured to run only if Step 3 passes.
5. **Step 5** — Add a post-ingestion DQ gate validating the Bronze/Raw asset; runs only if Step 4 passes.
6. **Step 6** — Add the transformation task, running only if Step 5 passes.
7. **Step 7** — Add a consumption DQ gate validating the Silver/Gold asset before downstream consumption.
8. **Step 8** — Wire the above into your DAG's execution flow.

**Recommended thresholds** (fully configurable per layer):

| Layer      | Asset                       | Threshold |
| ---------- | --------------------------- | --------- |
| Pre-flight | Source system               | ≥ 70      |
| Bronze     | Raw ingest asset            | ≥ 75      |
| Silver     | Curated asset               | ≥ 85      |
| Gold       | Reporting/consumption asset | ≥ 95      |

**Behavior:** if the DQ score meets the threshold the DAG continues; if it's below threshold the downstream tasks stop; if the asset isn't found the task fails; if Prizm is unavailable, behavior follows your configured retry/fail policy.

### Pipeline Analytics & Detailed Run Metrics

A pipeline health dashboard rolls up success/failure counts, freshness, and trend, filterable by domain, product, owner, or tag. Execution time and freshness are tracked at both the DAG-run and task-instance level — `execution_time` alerts if greater than 10 minutes by default, and `freshness` flags a silent failure such as a DAG expected hourly that hasn't run in 3+ hours.

### Log Coverage Model

Prizm formally scopes which Airflow log sources feed which capability: Task Logs (execution logs, exceptions, stack traces) are in scope for DAG/task failure detection and RCA; Scheduler, Worker, and Webserver logs are explicitly out of scope for this release.

### Customer-Managed Webhook Pattern & Managed Airflow Migration

For customers who prefer push-based over polling-based monitoring, the Plugin connection mode already pushes on Airflow's native event listeners; where a customer webhook endpoint is preferred instead, configure it under **Settings → Connect → Sources → Airflow → Webhook**. For customers migrating self-hosted Airflow from EC2 to EKS via the `KubernetesPodOperator`, no connector reconfiguration is required — point the existing API or Plugin connection at the new EKS-hosted Airflow endpoint.

\[Screenshot: Airflow lineage graph with root cause hypothesis panel showing linked GitHub PR]

***

## Azure Data Lake Storage (ADLS) Connector

Prizm now connects directly to Azure Data Lake Storage (ADLS) Gen2 — Microsoft's hierarchical, cloud-native file system built on Azure Blob Storage — to catalog, validate, and monitor structured, semi-structured, and raw files without ever copying or storing the underlying data. The connector runs as three modular Databricks Spark notebooks (Catalog Discovery, File Observability, and Quality Measures) orchestrated by Prizm, and reads files directly via the ABFS driver with no Unity Catalog table registration required.

\[Screenshot: ADLS asset catalog with file-level DQ scores]

### Authentication & Connection Configuration

1. Navigate to **Settings → Connect → Sources → Add Source → ADLS**.
2. Choose an authentication method:

| Method                                | When to use                                                | Credential stored                                        |
| ------------------------------------- | ---------------------------------------------------------- | -------------------------------------------------------- |
| Service Principal OAuth (recommended) | Production integrations; short-lived tokens auto-refreshed | Client ID + Client Secret, encrypted in Vault            |
| Storage Account Key                   | Dev/test environments; simpler setup                       | Account key, encrypted in Vault                          |
| Managed Identity (Azure)              | Prizm deployed in Azure; no credential management          | No credential stored — resolved at runtime via Azure MSI |

3. Fill in the connector fields: **Connection Name**, **Storage Account Name**, **Azure Region**, **Auth Type**, **Tenant ID**, **Client ID** / **Client Secret** (or **Storage Account Key**), **File Type** (CSV, Parquet, JSON, XML), and — under Advanced — **Databricks Workspace URL**, **Databricks Cluster ID**, and a scoped DQLabs API token.
4. Toggle **Use Vault** if you want credentials pulled from a configured vault instead of entered directly (see Vault & Secrets Management below).
5. Click **Test Connection** — this validates both ADLS access (container listing) and Databricks reachability before save is allowed.

Invalid credentials return a structured error identifying the specific failure (invalid client, wrong account, insufficient permission), and all credential types are interchangeable without re-creating the connector.

### Scope & Path Configuration

Define exactly what Prizm catalogs and monitors:

| Field                           | Description                                                                           |
| ------------------------------- | ------------------------------------------------------------------------------------- |
| Containers to include / exclude | Multi-select or wildcard patterns (e.g. `raw-*`, `finance-*`); blank = all containers |
| Root Directory Path             | Starting path within each container (e.g. `/data/`)                                   |
| Directory Depth Limit           | How many folder levels deep to crawl (default 5, max 10)                              |
| Partition Pattern               | Expected partition key structure (e.g. `year=/month=/day=`, `dt=YYYY-MM-DD`)          |
| File Types                      | CSV, Parquet, JSON, Delta, Avro, ORC (multi-select)                                   |
| CSV options                     | Delimiter, header row toggle, encoding                                                |
| JSON format                     | Newline-delimited (NDJSON) vs. single JSON array                                      |
| File Name Pattern               | Regex or date-token template (e.g. `sales_{YYYY}{MM}{DD}_*.csv`)                      |

This scope definition becomes the manifest the Catalog Discovery notebook uses as its starting point — files outside scope are never cataloged, and directory depth limits prevent runaway scans on deeply nested paths.

### Asset Discovery & Schema Inference

The Catalog Discovery notebook recursively traverses configured container paths, groups files into logical datasets by folder path and format (e.g. all Parquet files under `/silver/orders/` become one asset), and uses Spark's native readers to infer schema without creating tables. For Delta folders, it reads the transaction log directly to capture schema history, partition columns, and row count without a full data scan. Inferred schema is compared against the previously registered schema to detect drift (new/removed/renamed columns, type changes), and AI-powered classification (PII detection, domain tagging, glossary matching) is applied automatically. An **incremental mode** option processes only paths where the modification time has advanced since the last run, reducing compute on unchanged data.

### File Arrival & Control Checks

Configure an SLA for each expected file feed:

| Field                      | Description                                                                  |
| -------------------------- | ---------------------------------------------------------------------------- |
| Expected Arrival Frequency | Hourly / Daily / Weekly / Monthly / On-demand / Custom cron                  |
| SLA Deadline & Timezone    | The time by which the file must arrive                                       |
| Lookback Window            | How far back to check before declaring a file missing                        |
| Expected File Count        | Files expected per cycle (exact, range, or any)                              |
| Duplicate Detection        | Flags same-name or same-content-hash files arriving more than once per cycle |
| Missing / Late File Action | Alert only, flag in catalog, or alert plus auto-create incident              |

Missing, late, and duplicate files are flagged as separate issue types with distinct default severities (High for missing/late, Medium for duplicates), and full arrival metadata (arrival time, file size, SLA status, duplicate flag) is logged per event.

### File Format, Schema & Content Validation

Layered validation runs before deeper checks, so a corrupted file doesn't produce misleading downstream results:

1. **Format validation** — confirms the file matches its configured format and is readable; zero-byte files are flagged as reliability failures; corrupt or unreadable files are marked Critical and the asset is marked **REJECTED**.
2. **Header/Trailer/Detail (H/T/D) structure validation** — for fixed-structure files, the header and trailer rows must match configured type codes, and the trailer's declared record count must match the actual detail row count; a mismatch is a Critical structural failure.
3. **Schema validation** — column count, column names, and column types are checked against a baseline (auto-inferred, manually defined, or inherited from an existing catalog asset); missing columns are Critical, extra columns are a configurable Warning, and type changes generate a schema drift event.
4. **Record count & volume validation** — files must contain at least one data record; row counts are read for free from the Delta log, Parquet footer, or ORC statistics where possible (falling back to a Spark scan for CSV/JSON); a 7-day rolling anomaly check flags unexpected volume spikes or drops.

A composite DQ score — a weighted average across all rule results — is displayed as a badge on each ADLS asset, and any rule below its configured threshold automatically opens an Issue with fail count, failed record percentage, severity, and timestamp.

### Observability Metrics & Criticality Scoring

Prizm computes and surfaces, per asset: freshness (time since last modification, SLA status, minutes late), volume (row count, size, file count, % change), schema (column count, drift flags, added/removed/renamed columns), reliability (empty files, zero-byte files), and arrival control (arrival time, duplicate flag) — all pushed as time-series snapshots with no raw file content leaving Azure.

Each asset also receives a **criticality score** (Critical / High / Medium / Low), weighted from downstream consumer count, configured arrival frequency, file volume, historical reliability, and data sensitivity classification. Criticality auto-assigns a monitoring mode — **Max**, **Standard**, or **Chill** — that controls how aggressively checks run; the mode is overridable per asset and takes effect on the next job cycle without requiring reconnection.

### Job Scheduling & Orchestration

| Notebook module    | Default schedule | Trigger type                                  |
| ------------------ | ---------------- | --------------------------------------------- |
| Catalog Discovery  | Daily            | Scheduled + on new file detected              |
| File Observability | Hourly           | Scheduled + on file modification event        |
| Quality Measures   | On file change   | Event-driven, triggered by File Observability |

All three Databricks jobs are registered automatically on source save via the Databricks Jobs API — no manual job creation required. Retry policy and timeout thresholds are configurable from the connector UI, job health is polled via the Databricks Run Status API (failed runs surface as Prizm Issues), and an on-demand manual trigger is available from the Prizm portal for any of the three modules.

\[Screenshot: ADLS file arrival SLA monitor]

***

## Vault & Secrets Management

Building on Prizm's existing HashiCorp Vault integration (configured under **Settings → Integrations → Vaults**), the **Use Vault** option is now available on ADLS source connections, alongside the existing MSSQL and Databricks connectors.

1. Configure a vault at the tenant level first, under **Settings → Integrations → Vaults → Add Vault**, using AppRole-based authentication.
2. On any supported connector's configuration page (including ADLS), toggle **Use Vault** on.
3. Provide the secret path/key Prizm should use to pull credentials from the vault at connection time, instead of entering them directly.
4. Prizm expects a JSON-formatted secret at that path — for ADLS, this includes the storage account key or service principal client ID/secret depending on the chosen authentication method.

Every time a connection is established, Prizm checks the Use Vault flag; if enabled, it retrieves the secret from the vault at runtime rather than reading a stored credential, keeping secrets out of the Prizm database entirely for vault-managed connections.

***

## Issue Management

Prizm's Issue module is the remediation layer between detection (Alerts) and resolution tracking (SLA, Exception Records) — the tracked unit of work for actually fixing a data problem.

### Issue Creation & Sourcing

1. Issues are created **automatically** from Critical/High severity alerts, with metric, asset, alert message, and severity pre-populated — no manual step required.
2. To create one **manually**: open an asset, metric, or alert detail page (or the Issue module directly) and select **New Issue**.
3. If an open issue already exists for the same asset, Prizm prompts you to link to it instead of creating a duplicate.
4. Every issue receives a unique, immutable identifier at creation, and its source type (Structural, Pattern, or another configured category) is captured at that time.

### Issue Lifecycle & Status Management

Extends New / In Progress / Resolved with two new states:

* **Blocked** — set this when work is paused on an external dependency; a reason is required, and this automatically pauses the issue's SLA clock.
* **Reopened** — if the underlying alert re-fires after an issue was Resolved or Closed, the issue automatically moves to Reopened rather than spawning a new issue.

Every status change is timestamped, attributed to a user or system trigger, and recorded on the **Audit** tab.

### Alert–Issue Propagation

* If the source metric is deactivated or deleted, all linked issues auto-close with an appropriate reason.
* If threshold configuration changes, linked open issues are revalidated and their priority updated to match current alert severity.
* Resolving an issue updates its triggering alert's state if the alert hasn't already auto-resolved.
* A single issue can link to multiple alerts when the same underlying problem triggers repeated alerts on the same asset.

### Issue–Exception Record Relationship

1. Open the issue detail page — a count of linked exception records appears on the overview.
2. If **all** linked exception records are resolved, the issue is automatically flagged as ready for resolution.
3. If all are rejected, the issue status updates to reflect the underlying data wasn't actually anomalous.
4. Use **Bulk Resolve** from the issue detail page to resolve all linked exception records in a single transaction — logged in the Audit tab.

### Assignment & Ownership

1. Open the issue and use the **Assigned To** field to assign it to an individual.
2. Prizm shows a suggested default assignee (based on asset ownership or steward configuration) as a one-click option rather than auto-assigning.
3. Every reassignment logs the previous assignee, new assignee, timestamp, and the user who made the change.
4. Unassigned Critical/High issues older than a configurable threshold surface automatically on the dashboard as a triage gap.

### Issue Categorization & Taxonomy

1. Set the issue's **Category** (Structural, Pattern, or an Admin-configured type) at creation — filterable from the issue list.
2. Admins manage the category list under **Settings → Issue → Categories**.
3. Tags are inherited from the triggering alert by default and can be edited independently on the issue.

### SLA Binding & Duration Tracking

The old "Issue Duration" field (elapsed time only) is replaced with a full SLA-aware panel showing elapsed time, target, and remaining/overdue time. Moving an issue to Blocked automatically pauses its bound SLA clock; moving out of Blocked resumes it.

### Comments, Timeline & Audit Trail

| Tab          | Content                                                                                        |
| ------------ | ---------------------------------------------------------------------------------------------- |
| Conversation | Threaded comments with @mentions; mentioned users are notified                                 |
| Timeline     | Chronological view of status changes, assignments, and linked alert/exception activity         |
| Audit        | Immutable log of every field change and system event — cannot be edited or deleted by any role |

### External Ticketing Sync

From the issue detail page, select **Link External Ticket** and choose Jira, ServiceNow, or ADO. Title, description, severity, and the AI summary are pre-populated on creation, and status updates propagate back when the issue is resolved in Prizm.

### Issue Notifications

Reuses the same channel configuration (Email, Slack, Teams, PagerDuty, Webhook, in-app) already defined for Alerts, configurable per trigger under **Settings → Notifications → Issue Events**.

### Search, Filter & Saved Views

Filter the Issue list by status, severity, category, assignee, source, tag, and date range, then click **Save View** to name and store the combination — privately or shared with your team.

### Issue Page Revamp

General UI overhaul of the Issue list and detail pages to support the capabilities above in a single, consistent layout.

\[Screenshot: Issue detail page with AI summary, SLA panel, and linked exception records]

***

## SLA Management

A centralized SLA policy engine gives Prizm one reusable way to define and enforce time-based service commitments across Alerts, Issues, and Exception Records, instead of separate logic per module.

### SLA Policy Configuration & Management

1. Navigate to **Settings → SLA → Policies → New Policy**.
2. Set **Applies to Entity Type**: Alert, Issue, Exception Record, or All.
3. Set **Severity / Category Match** — which severities or categories this policy applies to.
4. Set the **Acknowledge Target** (optional) and **Resolve Target** (required).
5. Set the **Warning Threshold** — the % of the resolve target elapsed at which a pre-breach warning fires.
6. Toggle **Active/Inactive** and save.

Default tiers ship out of the box and are fully overridable:

| Severity | Resolve target     | Warning threshold |
| -------- | ------------------ | ----------------- |
| Critical | \< 8 hours         | 75% elapsed       |
| High     | \< 24 hours        | 75% elapsed       |
| Medium   | \< 3 business days | 75% elapsed       |
| Low      | \< 5 business days | 75% elapsed       |

Policies can be cloned without affecting the original, and policy changes only apply to entities whose clock starts after the change.

### SLA Clock Engine

The clock moves through **Not Started → Running → Paused → Warning → Breached → Stopped**, computing remaining time to the second. Pause/resume events are recorded with timestamp and reason and excluded from elapsed-time calculations.

### SLA Binding — Alert, Issue & Exception Record

* **Alert**: the clock starts automatically the instant an alert enters Firing state; alert SLA clocks do not support pause (continuous accumulation while Firing).
* **Issue**: supported pause reasons include Waiting on Customer, Blocked — Dependency, Waiting on Change Approval, and On Hold.
* **Exception Record**: individual records can carry their own SLA clock, independent of the parent alert or issue — useful when one alert produces many exception records with different resolution timelines. Bulk-resolving stops all associated clocks in one transaction.

### SLA Breach Notification Workflow

Warning-threshold crossings, acknowledge/resolve breaches, and clock resumptions each notify the assignee (with configurable escalation), reusing the same channel setup as Alerts under **Settings → SLA → Notifications**.

### Jira SLA Integration

Since Jira has no native SLA construct, Prizm auto-provisions custom fields the first time an SLA-bound issue is linked: **SLA Policy**, **SLA Status**, and **SLA Time Remaining**, alongside the native Due Date field. A Jira status transition mapped to a configured pause reason (e.g., moving to "Blocked") automatically pauses the Prizm SLA clock within one sync cycle.

\[Screenshot: SLA policy configuration screen with tiered thresholds]

***

## Microsoft Purview Integration

Prizm now integrates bi-directionally with Microsoft Purview, positioning Prizm as the data quality and observability layer that both enriches and is enriched by Purview's governance catalog.

### Authentication & Connection Configuration

1. Navigate to **Settings → Connect → Sources → Add Source → Microsoft Purview**.
2. Enter **Connection Name**, **Purview Account Name**, **Tenant ID**, **Client ID**, **Client Secret**, and **Scope** (auto-populated as `https://purview.azure.net/.default`).
3. In Purview, assign the service principal **Purview Data Reader** (read access), **Purview Data Curator** (required for push), and **Collection Admin** (only if using custom metadata types).
4. Click **Test Connection** to acquire a token and validate against a Purview search API before saving.

Tokens are valid for 1 hour and auto-refresh before expiry; TLS 1.2+ is enforced on all connections.

### Metadata Extraction, Classification & Push

Once connected, Prizm extracts entity metadata (tables, columns, databases/schemas, Power BI assets, ADLS paths) on the regular Catalog Job cycle, using `qualifiedName` for stable deduplication and incremental extraction after the first crawl. Purview classifications and Microsoft Information Protection sensitivity labels are pulled and mapped to Prizm tags (customizable under the connection's Classification Mapping page). Curated metadata — summaries, alerts, issues, and measures — is pushed back into Purview at the Asset, Attribute, and Domain level; an AI-generated description is only pushed once a human user has accepted it.

### Custom Metadata Types & DQ Score Push

Prizm defines custom Purview attribute types (`prizm_dq_score`, `prizm_criticality`, `prizm_rule_count`, `prizm_rules_passing`, `prizm_freshness_hours`, `prizm_last_assessed`, `prizm_alert_count`, `prizm_asset_url`) via the Purview type-definition API, requiring the Collection Admin role. DQ scores and quality metrics push automatically whenever an asset's score changes by ≥1 point, plus a full daily sync, with an on-demand push also available from the connector settings page.

### Governance Alignment & Glossary Sync

Prizm extracts Purview governance domains and data products and surfaces them on the corresponding asset page; conflicts with Prizm's own domain assignment are flagged for steward review rather than silently overwritten. Purview glossary terms and critical data elements are pulled in to enrich asset descriptions and guide AI-generated descriptions, and assets containing a critical data element receive a criticality-score boost.

\[Screenshot: Purview integration health dashboard]

***

## AI Guardrails & Platform Controls

As Prizm's AI footprint has grown, this release adds the first layer of organization-wide control over where and how AI is used.

### Turning AI Off Platform-Wide

1. Navigate to **Settings → Platform → LLM Provider**.
2. Select **None** as the provider. Both the Quick Reasoning and Deep Reasoning model pickers become disabled.
3. Every AI-enabled surface across the platform displays **"AI-generated insights are turned off"** instead of disappearing, with a link back to this setting.
4. AI icons (sparkle, refresh) switch to a grayed-out state.

### Module-Level AI Toggles

Independent of the global switch, AI can be turned on/off per module under **Settings → Platform → AI Controls**: Asset, Metric, Alert, Issue, Context, and Converse (the AI chatbot).

### Write-Action Restriction & Risk Register

The AI layer is hard-blocked from executing update or delete queries under any prompt — a request that would require one returns *"Update/Delete are not permitted actions"* instead of executing. Every AI-assisted feature in the platform now has a documented risk and mitigation, generally following two patterns: **suggest-only by default** (recommendations require explicit human acceptance before being applied) and **grounded generation** (AI output is generated from the platform's own computed data where possible, labeled with an "AI-generated" badge).

\[Screenshot: AI guardrail settings with module-level toggles]

***

## Autonomous Layer (AI Chatbot) Enhancements

**Mintlify documentation integration** — The Prizm AI Chatbot now integrates with the Mintlify MCP server behind the official documentation site. Ask the chatbot a product question and it retrieves the answer from the official user guide rather than relying on general model knowledge alone.

**GPT performance & stability** — A round of latency and stability fixes across the chatbot's underlying agent tools (asset, metric, schedule, governance, and lineage agents), reducing response time and error rates for common conversational workflows.

***

## Exception Management Enhancements

### SLA-Based Exception Management

1. Exception records inherit the SLA defined on their parent alert or issue by default, or can be configured with their own SLA at the **metric level** under **Settings → Exception → SLA Configuration**.
2. For each metric, configure: SLA duration, notification channel(s), notification recipients, escalation timing, and notification frequency.
3. The SLA timer starts the moment the exception record is **first written to the Exception Repository** — not at workflow creation, metric execution, or assignment time.

### Exception Incremental Logic — Auto-Resolve

During every metric/workflow execution, Prizm validates previously flagged exception records against the latest source data. If the underlying condition has cleared (the record no longer violates the metric rule) or the record no longer exists in the source, its status automatically becomes `AUTO_RESOLVED` — removing the need to manually close exceptions that have already self-corrected upstream.

### Exception Record Notifications

Configure notification rules under the exception workflow's **Actions** tab. Assigned users are notified on new assignment and on reassignment, and external recipients can be added under **Audience → External Email**.

***

## SSO / SCIM & Access Management

**SailPoint SSO & SCIM integration** — Adds SailPoint as a supported SSO/SCIM identity provider alongside the existing Okta, IBM, Ping, and Azure integrations. Configure under **Settings → Platform → Identity Providers → SailPoint**.

**Auto group-creation control for SSO** — Previously, Prizm always created a new user group automatically the first time it saw a new group attribute from the SSO provider. Admins can now turn this off under **Settings → Platform → Identity Providers → \[provider] → Auto Group Creation**, so incoming SSO attributes are matched only against existing groups rather than silently creating new ones.

***

# Improvements

## DBT Pipeline & Root Cause Enhancements

### DBT Test Score

dbt test results now contribute to an asset's Prizm data quality score rather than surfacing only as a pass/fail flag.

**Formula:** `dbt Test Score = (Total Rows − Failed Rows) / Total Rows × 100`

Failed rows come from dbt's `run_results.json`; total rows come from `catalog.json` row-count stats when available (requires `dbt docs generate` in the same job), falling back to Prizm's existing profiling metadata otherwise.

**To configure:** open your DBT connector's **Configuration** screen, and under **Model Scoring** choose **Based on DBT tests** (new default, scores each test using the formula above) or **Based on the underlying asset** (previous behavior). The resulting score displays on the DBT model page and next to the materialization on the underlying asset page.

**Known limitation:** the failure ratio is only mathematically valid for row-grain tests; built-in `unique`/`accepted_values` tests return one row per failing value rather than per failing row, so scores for these test types are approximate.

### Prizm dbt CLI — Now Published to PyPI

The `prizm-dbt` CLI plugin used to push dbt Core artifacts to Prizm is now published as a standard PyPI package, so teams can add it to any CI/CD pipeline with a plain `pip install prizm-dbt` instead of a custom install step. The plugin runs as an explicit, separate step after your existing dbt commands (it does not execute dbt itself), operating purely on the artifact files already on disk — safe to drop into CI/CD, Airflow, GitHub Actions, or Jenkins. Key commands:

| Command                                                              | Purpose                                                                                                                                  |
| -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| `prizm-dbt push-artifacts --project-dir <path> --target-path <path>` | Collects `manifest.json`, `run_results.json`, `semantic_manifest.json`, and `catalog.json` from a prior dbt run and pushes them to Prizm |
| `prizm-dbt validate`                                                 | Preflight check — confirms the auth token is valid, the Prizm endpoint is reachable, and required files/permissions are in place         |
| `prizm-dbt doctor`                                                   | Diagnostics: resolved paths, detected artifacts, environment context, connectivity, and the result of the most recent push               |

Every push includes mandatory execution context (environment, dbt target, dbt version, adapter type, project identifier, invocation timestamp, execution status) for lineage versioning, observability, and historical replay. Authentication is token-based; tokens are never logged or printed, and TLS is enforced.

### Investigate Agent — Explains Root Cause from PR Changes

When the Investigate Agent identifies a GitHub pull request as a likely root cause, it now generates a plain-language explanation of *what changed and why it's the likely cause*, alongside the PR diff — rather than linking to the diff and leaving interpretation to the user.

### Investigate Agent — Dynamic PR Lookback Window

Previously, root cause investigation only considered PRs merged within a static 48-hour window before the alert, which could miss relevant changes when the affected asset (or an upstream asset) hadn't run since before that window. Prizm now uses the **last successful run time** of the current asset — and all upstream assets — as the starting point for PR relevance, falling back to the 48-hour window only when no successful run exists.

## Metric Enhancements

### Expanded Schema-Change Checks

The schema metric now detects, for every connector, column additions, deletions, renames, data-type changes, and length/constraint changes — captured with old/new values for each changed column.

### Schema Changes on the Asset Overview Page

Schema-level changes now ripple through the asset overview: a change-count badge on the Schema tile links to a timeline of what changed, the Description card shows a "schema changed since last review" warning with a re-verify action, downstream lineage highlights impacted assets in amber, and the Context/Freshness panel calls out recent schema changes directly. The detail timeline is color-coded by outcome (amber for schema change, red for alert raised, green for a clean run), with a diff panel showing before/after values and downstream impact per run.

### Asset Change Detection & Status Tracking

For any non-attribute catalog object, additions, changes, and deletions are captured with name, type, timestamp, and user, and drive an automatic status update: newly added assets start as **Pending**, deleted assets move to **Deprecated**, and changed assets revert to **Pending** even if they were previously Verified or Ready for Review — all recorded in the audit trail.

### Parametric Metric

A new **Parameter** metric type lets one measure definition accept runtime input parameters (date range, region, threshold, segment) — sourced from the bound asset, an organization-level constant, or any metadata field — and run the same SQL logic across different contexts.

**To create one:** write your SQL using `{{param}}` tokens in the measure editor; Prizm auto-detects the parameters used at save time. Click **Run**, and you'll be prompted for input values before execution. This works in both the UI and via the API (which accepts a `parameters` payload and returns the run ID, status, computed value, and effective parameters used). Every run stores the resolved SQL and effective parameter values for audit purposes.

### Enhanced Threshold Configuration & Alerting Framework

Refinements to how thresholds are configured and evaluated for metric-based alerting, improving consistency between the configured threshold and the resulting alert behavior — review threshold settings under each metric's **Edit Configuration → Alerting** tab if you rely on custom thresholds.

### Metric Status Defaults to Inactive Until Approved

Based on direct customer feedback: if a metric's status is anything other than **Approved** (i.e., still Pending or Ready for Review), it now defaults to **Inactive** rather than running. This prevents unreviewed metric logic from generating alerts or contributing to scores before it's been through the approval workflow.

### Metrics Feedback — Customer-Driven

A further round of fixes and refinements to metric configuration and display based on direct customer feedback on the Metrics module.

## Governance Enhancements

A set of improvements to the Governance module driven by direct customer feedback:

* **Sub-domain visibility and selection** — Domains and sub-domains previously appeared bunched together in the same list, making it hard to identify the correct sub-domain and allowing both a sub-domain and its parent domain to be selected redundantly at the same time. Sub-domains now render as a hierarchical view (similar to the Domains page): selecting a sub-domain auto-selects and grays out its parent domain, and once applied, the asset displays both — for example, "Supply Chain – Planning" instead of just "Planning."
* **Source configuration** — Improvements to adding tables under a source: the table list no longer needs to fully populate before you can start selecting, table names can be copied and pasted into the search field, and a checklist view lets you select multiple available tables at once instead of searching one at a time.
* **Dashboard trend** — Metric-level trendlines are now available (previously only asset-level), with an additional score line alongside the actual value on every metric timeline; dashboard analytics can also break down DQ trend by application, product, or tag, not just domain.
* **Search bar** — Search now returns real results across assets, terms, glossary, and other object types instead of always redirecting to the Asset page, with a dedicated Semantic section positioned between Assets and Documents in the results, and filtering to narrow results by type (asset, glossary, term, policy, etc.).
* **General governance feedback** — Domain pages now support "Asset Type" as a configurable column on Linked Assets (matching the Metrics view); glossary Terms inherit their Domain and Glossary association automatically rather than needing manual re-entry; Terms can now be added directly from a Category page rather than only from the parent Glossary page; and ingested tags can be filtered out or removed after ingestion rather than only at the point of ingestion.

## Analytics Dashboard Enhancements

**Data observability dashboard** — A new static dashboard surfacing signal coverage: scorecards for the % of tables with no freshness issues, no volume anomalies, and no custom measure violations, plus "noisiest tables" breakdowns for each signal over the last 7 days.

**Data quality dashboard** — A new static dashboard surfacing quality metrics: custom measure count with growth trend, a dimension-by-dimension breakdown (Accuracy, Completeness, Timeliness, Consistency, Validity, Uniqueness) with violation counts and scores, and test coverage by domain.

## Platform Navigation & Catalog UX

### Settings & Navigation Menu Reordering

The Settings menu is reorganized into a clearer hierarchy:

* **Platform** — Configuration, Token, Storage, Metadata (Field, Overview: Summary/Culture/Architecture/Governance/Theme, Dimension)
* **Security** — SAML/SSO, Access
* **Integration**
* **Remediation**

In the main product navigation, **Access** moves out of the top-level menu into Settings, **Audience** becomes its own separate menu item, and a new **Semantic** menu groups Product, Application, Tag, and Domain together in one place. Permission sets have been reviewed and extended so every menu item under the new structure has an appropriate permission gate.

### Catalog Page Improvements

A batch of usability fixes across asset, metric, and domain pages based on direct customer feedback:

* The Definition and Description fields now render on separate lines when editing, instead of running together.
* AI-generated Context now regenerates correctly when manually triggered, instead of silently failing to update.
* Custom fields can now have their own descriptions, and can be scoped to a specific object type (e.g., Asset only) instead of appearing by default across every object type including ones where they don't apply.
* AI Insights cards now expand to fit their full content instead of being cut off.
* Status changes (e.g., to Approved) are now gated by the corresponding permission set rather than being available to any role regardless of assigned permissions, and approval comments are captured whenever a status changes on an Asset, Metric, Domain, Product, Application, Term, or Tag.
* Metric cards resize dynamically so they consistently fit on one line regardless of count, and card overflow on pages with many cards now scrolls instead of breaking the layout.
* A new **Propagation** section (under object Properties) lets admins configure how ownership and semantic context (Domain, Product, Application, Tag) cascade from a source or domain down to its tables, schemas, columns, and metrics — including whether propagated values can be locally overridden at any level, and whether domain-level assignment takes priority over source-level assignment when both are present.

## Logging Enhancements

**Job-level log improvements** — Enhancements to job-level logging for clearer visibility into individual job execution details.

## Scheduling

**Event-driven scheduling** — Adds support for event-based schedule triggers alongside the existing time-based model. Configure under **Settings → Platform → Schedules → New Schedule → Trigger Type → Event**, and select the upstream event that should kick off this job.

***

<Note>
  Screenshots referenced above (\[Screenshot: ...]) are placeholders — please attach the corresponding product screenshots before publishing.
</Note>