Data governance journey

Discover, Standardize, Improve, Govern, and Use connect product capabilities into tasks. This is not a mandatory linear process or a statement of licensing, deployment, or API dependencies. Start at the stage relevant to your goal and return when results need correction.

Stage	Goal	Capabilities	Outputs
Discover	Locate, understand, and trace data	Metadata, basic lineage, SQLink	Inventory, metamodels, lineage, harvesting state
Standardize	Align names, definitions, metrics, and structures	Standards and metrics; DDM modeling and architecture	Standards, codes, metrics, mappings, design constraints
Improve	Identify and resolve quality issues	Data Quality	Rules, results, issues, remediation
Govern	Manage ownership, value, and security	DDC, DDS, Security Gateway	Catalog, classifications, levels, policies, audit
Use	Discover, request, and use approved data	Marketplace, services, data context	Requests, approvals, APIs, authorized calls, validated context

Define goals and responsibilities

Start with a bounded goal, such as making a subject area's data understandable, testable, and requestable. Record objects, sources, consumers, and acceptance criteria. Prepare accounts, sources, roles, and approvals through system setup.

Responsibility	Owns	Handoff
Data owner	Definitions, ownership, usage requirements	Standards, quality, security, asset owners
Data steward	Descriptions, mappings, remediation coordination	Domain reviewers
Metadata/lineage administrator	Sources, harvesting, parsing	Standards and analysts
Standards administrator/reviewer	Draft, review, publication	Field maintainers and quality designers
Quality administrator/issue owner	Validation, assignment, remediation, verification	Asset owners and consumers
Security/asset administrator	Classification, policy, catalog, publication	Approvers and delivery teams
Consumer	Requirements and acceptance	Business owners

Configure these suggested responsibilities through role management. Separate drafting and final review where practical. Check license, functional, catalog, and data usage permissions independently.

Discover resources and relationships

Inputs: systems, connections or offline metadata, owners, scripts, and report sources.

1. Register sources and test connectivity.
2. Harvest metadata within explicit scope and inspect logs and objects.
3. Verify tables and fields, enrich Chinese business names and descriptions, and use report/file management and object maintenance.
4. For custom resources, design metamodels and import objects.
5. View basic lineage, or build advanced paths through SQLink resources and parsing.

Check: distinguish connectivity from harvesting completion; verify source, schema, and object identity; resolve parsing failures and missing metadata. An empty graph does not prove no dependencies.

Handoff: inventory, accessible objects, descriptions, and traceable paths to standards and quality owners. Return missing resources to harvesting.

Standardize definitions and mappings

Inputs: inventoried metadata, policies, vocabulary, reference values, metric definitions.

Modeling and architecture belong to DDM. See DDM documentation (Chinese) for its operations.

1. Build standard catalogs and maintain codes and dictionaries.
2. Use business domains, domain standards, and dictionaries for separation and reuse.
3. Complete the publication lifecycle.
4. Map fields, using reviewed Intelligent Matching and Grouped Recommendations for larger scopes.
5. Validate mappings and inspect usage reports. Use metric standards for definitions and Metric Management for atomic, calculated, or qualified metrics and queries.

Check: similar names do not establish equivalent meaning; published standards are not automatically mapped; mapping does not validate actual values.

Handoff: approved definitions, codes, metrics, and mappings. Resolve technical mismatches through mappings or standard changes; send value problems to quality validation.

Improve quality through verified remediation

Inputs: requirements, scope, stable record identifiers, and accountable owners.

1. Publish business rules.
2. Implement technical rules. SQL should select exceptions; supported regular expressions describe valid formats.
3. Run a small validation task and check its report.
4. Inspect issues and assign owners with catalog access.
5. Close remediated issues, inspect verification, and reopen failures where permitted.
6. Retain causes, fixes, and recheck methods in knowledge resources.

Check: execution success, closure, and full verification differ. Rules with automatically created primary keys cannot support verification and are unsuitable for persistent record-level tracking.

Handoff: rules, runs, issues, remediation, and verification. Return unclear semantics to standards or incomplete objects to discovery. Supply evidence beyond a score when publishing assets.

Govern ownership and protection

Cataloging and security can proceed in parallel; validate publication and access independently.

Catalog and publish

1. Define space types, levels, attributes, and approvals.
2. Set directories, owners, and permissions.
3. Register assets, optionally confirming inventory recommendations.
4. Approve directories, child directories, and assets separately; test consumer visibility.

Directory completeness measures filled attributes, not data quality. Inventory acceptance mounts assets without publishing them. An unpublished parent can hide a published asset.

Classify and control access

1. Define classification and levels, with legal basis.
2. Use collaborative classification, workbench, or discovery tasks, then review and publish. Maintain algorithms as needed.
3. Define identity, row scope, and masking in policies.
4. Configure server and JDBC client.
5. Verify results and audit using actual business identities.

Classification publication does not enforce a policy automatically. Direct database and gateway access differ. Browsing permission is not data usage permission.

Handoff: discoverable assets, ownership, reviewed security decisions, policies, and runtime evidence to approvers and delivery teams.

Use data through requests and acceptance

Alongside products and APIs, organize verified asset knowledge into DIG context for users and agents.

1. Discover products and inspect details and cart.
2. Check definitions and scope; request browsing access if needed.
3. Apply immediately for one product, use the cart for several, or submit a text requirement when none fits.
4. Track approvals.
5. Coordinate offline delivery by IT or the responsible team.
6. Accept delivery against the approved purpose and scope.

A cart is not a request; submission is not approval; approval is not delivery. DAM records the decision without automatically delivering files, accounts, or interfaces.

For API delivery, create, test, and publish in Data Services, then request through the API marketplace. Marketplace product approval does not grant API authorization.

Use SQLink for change analysis

Inspect operator lineage for processing and scenarios for impact. Validate harvesting and parsing first. After changes, refresh metadata, inspect history, reparse, sample paths, then check standards, quality, and asset descriptions.

Try the fictional SQL tutorial to learn graph reading. It is not evidence of enterprise coverage. Use query APIs for integration.

Use DIG for assistance and context

Follow the quick start for proposals, approvals, and target verification. Use spaces and context publishing for a business topic, or end-to-end governance for assessment, inventory, Routines, proactive tasks, scorecards, and MCP. DIG is optional; module workflows remain usable without it.

Start from a problem

Problem	Path	Acceptance focus
Unknown location or owner	Register > harvest > verify and describe	Traceable sources and responsibility
Conflicting definitions or codes	Define > publish > map > validate	Correct meaning and field identity
Invalid data	Business rule > technical rule > task > remediate	Stable exceptions and re-verification
Assets hard to find	Space design > inventory > publish > marketplace	Consumer discovery and understanding
Different users need different access	Classify > policy > JDBC > verify	Identity, scope, masking, audit
Reuse data through APIs	Develop > test/publish > authorize > monitor	API, application, and result alignment
Change may affect consumers	Reharvest > parse > inspect > assess	Reliable dependencies and owner review

Record handoffs

Maintain a project record or existing ticket; this is not an automatically generated cross-product status object.

1. Identify the same object by system, source, schema, table, and field, plus name and owner.
2. Hand off published standard code, definition, values, and field mappings; confirm shared meaning.
3. Hand off rules, runs, issue scope, verification, unresolved owners, and plans.
4. Hand off reviewed classification, level, purpose, policy identities, and actual access evidence.
5. Hand off catalog position, ownership, publication, and visibility for directories and assets separately.
6. Hand off approved purpose and scope to the delivery team, then record consumer acceptance.
7. Record missing paths, failed verification, pending approvals, and undelivered content.

Respond to change

Change	Check first	Then inspect
Table, field, or type	Harvesting and history	Mappings, rules, lineage, descriptions
Standard or reference values	Change approval and references	Field applicability, mapping and data checks
Persistent exceptions	Data, remediation, verification	Unfixed data, inapplicable rule, wrong identity
Level or user changes	Review, policy, membership	Actual JDBC results and audit; separate offline permissions
Catalog or asset withdrawal	Scope and approval	Parent/child visibility and consumer communication

End-of-cycle evidence

Area	Evidence
Accurate objects	Sources, harvesting, descriptions, relationships
Consistent semantics	Published standards, mappings, validation
Resolved issues	Runs, owners, remediation, verification
Controlled assets	Ownership, publication, levels, runtime access
Traceable use	Requests, approvals, delivery, acceptance
Sustainable maintenance	Schedules, change impact, open items, next scope