Data Governance¶

What changes for glossaries, classifications, policies, workflows and access governance.

Policies & roles¶

Five new task operations¶

Behavioural · Affects: custom policies, non-admin users, bots

resourceDescriptor.json gains CreateTask, EditTask, ResolveTask, CloseTask, ReassignTask. With the Task redesign, task actions are policy-governed rather than implicit.

The 2.0.0 migration seeds a new TaskAuthorPolicy, attaches it to the DataConsumer role, and adds task rules to DataConsumerPolicy and ApplicationBotPolicy.

{
  "name": "DataConsumerPolicy-CreateTask-Rule",
  "resources": ["task"],
  "operations": ["Create"],
  "effect": "allow"
}

Self-approval guard¶

Task authorization in 2.0 refuses to let a task's creator approve their own task, even where policy would otherwise allow it. Approval automation that submitted and approved with the same service account must be split across two principals — or use emptyAssigneeStrategy: assignAdmins (see below).

AutoClassificationBotPolicy gains Topic¶

The migration appends AutoClassificationBotRule-Allow-Topic (EditAll, ViewAll on Topic) so the auto-classification bot can tag messaging assets. See Auto-classification for topics and containers.

Reviewer authorization shortcut removed on create¶

A shortcut that granted reviewer-level authorization on CREATE was removed. Flows that relied on being a reviewer to create an entity now need an explicit Create grant.

Glossary & ontology¶

Native OWL/RDF ontology import¶

New capability

PUT /v1/glossaries/name/{name}/importRdf

Imports an OWL/RDF ontology into a glossary, preserving identity for round-trips. Two new fields support this:

Glossary term relation semantics¶

· Affects: glossaryTermRelationSettings

Relation types gain OWL property characteristics used for RDF round-trip and optional validation (not enforced by default):

Other 2.0 changes in this area:

• Glossary term relation types are readable by any authenticated user (previously restricted).
• Glossary term relation settings are paginated.
• All relation types between the same term pair are preserved (previously one could overwrite another).
• Glossary rename now cascades to child terms in the search index, and approval workflows stay valid across term move and rename.
• CSV import/export preserves domains, and entityStatus is parsed case-insensitively.

Classification, tags & auto-classification¶

Auto-classification extends to topics and containers¶

· Affects: PII/classification coverage and bot permissions

Two new pipeline schemas ship:

• metadataIngestion/messagingServiceAutoClassificationPipeline.json
• metadataIngestion/storageServiceAutoClassificationPipeline.json

Together with the AutoClassificationBotPolicy Topic rule, this means topics and storage containers are now auto-classified where previously only database tables were.

PII recognizer accuracy changes¶

Behavioural — existing tags may be wrong, new runs differ

The CvvRecognizer regex is anchored by the 2.0.0 migration:

-- from  \b\d{3,4}\b   to   \A\d{3,4}\Z

The unanchored pattern matched the 125 inside values like SCN-125, so any column whose name carried a CVV context word (code, card, cvv, …) and whose values contained a 3–4 digit run was tagged PII.Sensitive — scenario_code, error_code. Because the context boost sets the score straight to MAX_SCORE, a 0.5-confidence pattern became a certain match.

Related fixes in 2.0:

• Overly broad context keywords removed from PII recognizers.
• Plain code columns are no longer tagged as PII.
• Sibling-tag score ties are broken by column-name match.
• Temporal table period columns are excluded from auto-classification sampling.
• Recognizer inclusion is resolved correctly by language, including any-language recognizers.
• The content/column-name split was removed from classification scoring.

Other classification changes¶

Governance workflows¶

userApprovalTask gains task-lifecycle configuration¶

· Affects: existing workflow definitions (backwards compatible)

{
  "emptyAssigneeStrategy": "none | assignAdmins",
  "stageId": "…",
  "stageDisplayName": "…",
  "taskStatus": "Open | InProgress | …",
  "assigneeStrategy": "…",
  "transitionMetadata": [ { "id": "approve", "label": "Approve" } ]
}

emptyAssigneeStrategy (default none) controls what happens when no reviewers, owners or candidates resolve to an assignee:

The stageId / stageDisplayName / taskStatus / transitionMetadata fields are written onto the Task while the user task is active — this is what surfaces workflow stage and available transitions in the Tasks UI.

New workflow node subtypes¶

Definitions: governance/workflows/elements/nodes/automatedTask/policyAgentTaskDefinition.json, .../createAndRunAIAutomationTask.json.

Workflow trigger fields¶

type/workflowTriggerFields.json adds entityStatus; inputPorts, outputPorts and glossaryTerms also become trigger fields.

Workflows fire far sooner¶

Behavioural · Affects: every governance workflow

The 2.0.0 migration lowers three intervals on existing deployments:

Approval tasks now appear near-instantly after the triggering change instead of up to 10 s (or, under load, minutes) later.

Workflow migrations run inside a try/catch in v200: a WorkflowHandler failure logs and continues rather than aborting the rest of the data migration. If you see "Failed to initialize WorkflowHandler … in v200" in the upgrade logs, restart the server to complete workflow wiring.

Data Access Requests & the Policy Agent¶

New capability

2.0 introduces self-service data access requests backed by a Policy Agent that executes grants and revokes against the source system.

{
  "principalType": "USER | ROLE",
  "principal": "analyst@example.com",
  "databaseName": "…", "schemaName": "…", "tableName": "…",
  "accessType": "FullAccess | ColumnLevel | Masked | Revoke",
  "requestedAccess": "Read | Write | Admin"
}

Revoke tears down whatever the principal currently holds at the scope — it is not a level-specific revoke.

policyAgentConfig defaults are backfilled onto existing services¶

Behavioural · Affects: existing Snowflake, Databricks and Unity Catalog services

Schema-level defaults only apply at create-time deserialisation, so the 2.0.0 migration rewrites stored rows. Operator-set true values are preserved; only false/missing values are changed.

An earlier revision of the migration forced Databricks supportsMaskedAccess to true; 2.0 includes a corrective heal that resets it to false on every Databricks row.

supportsPolicyAgent is also declared as an identifier on all database connectors so the UI can show or hide the Policy Agent option in the Add Agent dropdown.

Domains & data products¶

— no breaking changes in this area for 1.13 → 2.0.

Intake forms¶

New capability

governance/intakeForm.json and POST /v1/governance/intakeForms add structured intake forms, used together with taskFormSchema to drive request/approval workflows with typed inputs.

AI Governance Studio¶

New namespace · Collate distribution

A complete AI governance surface is added to the 2.0 spec:

Backed by ai_governance_framework_entity, ai_framework_control_entity and audit_report_entity tables created in the 2.0.0 migration.

Collate AI agents removed¶

app.json's agentType enum drops CollateAI, CollateAITierAgent and CollateAIQualityAgent — only Metadata remains. Their config schemas are deleted:

• entity/applications/configuration/external/collateAIQualityAgentAppConfig.json
• entity/applications/configuration/external/collateAITierAgentAppConfig.json
• entity/applications/configuration/private/internal/collateAITierAgentAppPrivateConfig.json