Dataplex is Google Cloud’s service for discovering, understanding, governing, and trusting data that is scattered across many systems.

The problem: data everywhere, trust nowhere

A modern company stores data in many places at once. Sales figures sit in a data warehouse. Raw logs sit in storage buckets. Customer records live in operational databases. Machine learning features sit in yet another system. Each team builds its own tables, names its own columns, and fixes its own errors. Soon nobody knows what data exists, which copy is correct, where a number came from, or who is allowed to see it.

This causes real damage. Analysts spend more time hunting for data than analyzing it. Two dashboards show different revenue figures, and nobody can explain why. A privacy officer cannot answer which tables contain personal information. An engineer changes a column and silently breaks twelve reports. The root cause is the same each time: the company has data but lacks reliable information about its data.

Information about data is called metadata

Metadata means data about data. The name of a table, the meaning of a column, the owner of a dataset, the date it was last updated, and the quality score of its contents are all metadata. Managing metadata well is the foundation of data governance, because you cannot protect, fix, or share what you cannot describe.

A note about names and history

Names in this area have changed several times, so it helps to know the story. Google first offered a service called Data Catalog for tagging and searching data. It then introduced Dataplex, which organized data into lakes, zones, and assets and added quality checks and discovery. Later the catalog features were presented as Dataplex Universal Catalog. According to Google’s documentation, on April 10, 2026 Dataplex Universal Catalog was renamed Knowledge Catalog. Google states that the API, client library, command line tool, and permission role names did not change, so the technical name Dataplex still appears in endpoints and roles.

Because many engineers, tutorials, and tools still say Dataplex, this guide uses Dataplex as the main name and mentions Knowledge Catalog where it matters. The ideas are the same under either name.

A handful of data governance ideas explain nearly everything in Dataplex.

Governance vocabulary can sound heavy, but each idea is simple. Learn these eight terms and the rest of the guide will feel natural.

Technical metadata and business metadata

There are two flavors of metadata. Technical metadata describes the machine side: column names, data types, sizes, and update times. Much of it can be collected automatically. Business metadata describes the human side: what a table means, who is responsible for it, how sensitive it is, and which business term it represents. People usually have to add it, though modern tools can help suggest it. A good catalog holds both, because analysts need meaning as much as structure.

Governance is more than blocking access

Many people hear “governance” and picture a locked door. Good governance is closer to a well-run airport. It makes sure the right passengers reach the right gates quickly, with clear signs and safety checks that people trust. The aim is not to stop data use but to make safe, confident data use easy.

Dataplex bundles several capabilities that work together around one shared metadata layer.

It helps to see Dataplex as a toolbox rather than a single tool. Each capability solves one problem, and they reinforce each other because they share the same catalog. Google’s use-case documentation groups them under search and retrieval, enrichment and metadata management, aggregation, governance, data quality and profiling, and data lineage.

flowchart TD
  SRC["Data sources: BigQuery, Cloud Storage, databases, streams"] --> CAT["Shared metadata catalog"]
  CAT --> SEARCH["Search and discovery"]
  CAT --> GLOS["Business glossary"]
  CAT --> DQ["Profiling and data quality"]
  CAT --> LIN["Lineage"]
  CAT --> GOV["Governance policies"]
  CAT --> DP["Data products"]
        

Read the diagram from the top. Information about your sources flows into one shared catalog, and every other capability reads from and writes to that catalog. This is why a quality score can appear on a table’s catalog page, why lineage can show glossary terms, and why a governance rule can follow a table wherever it appears.

How it relates to other Google Cloud services

Dataplex does not replace storage or processing tools. BigQuery still stores and queries tables. Cloud Storage still holds files. Dataproc and Dataflow still process data. Dataplex sits across them, describing and watching what they do. Google’s documentation lists metadata sources such as BigQuery, Vertex AI, Bigtable, Spanner, Pub/Sub, and Cloud Storage, along with connectors for third-party systems.

The catalog uses entries, aspects, and groups, which work like index cards, fill-in forms, and drawers.

Entries

An entry is the catalog’s record for one data asset. Google’s documentation gives the example of a BigQuery table, which becomes an entry identified by its project, dataset, and table name. Columns appear on the entry when a schema aspect is attached to it. Every searchable thing in the catalog is an entry.

Aspects and aspect types

An aspect is a group of related metadata fields attached to an entry, for example an “ownership” aspect with fields for team and contact, or a “sensitivity” aspect with a classification level. An aspect type is the reusable template that defines which fields an aspect has. Aspects are stored inside the entry they describe rather than as separate objects. Google states that aspect types succeed the tag templates of the older Data Catalog service.

Entry types and entry groups

An entry type is a template saying which aspect types an entry of that kind must carry, so every BigQuery table entry looks consistent. An entry group is a container for entries. According to Google’s documentation, the entry group is where you set access control, project attribution, and location for the entries inside it. Think of it as a labeled drawer with its own lock.

Entry links

Assets do not live alone, so the catalog also records relationships through entry links. The documented link types are synonym, related, definition, and schema-join. A synonym link says two terms mean the same thing. A definition link connects a glossary term to the asset or column it defines. A schema-join link says two tables can be joined on certain columns. Links can be symmetric or directional, and many can point to a specific column.

flowchart TD
  EG["Entry group: a drawer with its own access rules"] --> E1["Entry: sales orders table"]
  EG --> E2["Entry: customers table"]
  ET["Entry type: required aspect types"] -.-> E1
  E1 --> A1["Aspect: schema"]
  E1 --> A2["Aspect: ownership"]
  E1 --> A3["Aspect: sensitivity"]
  E1 -- "schema-join link" --> E2
  GT["Glossary term: Customer"] -- "definition link" --> E2
        

The diagram shows one drawer holding two entries. The orders entry carries three filled forms and a join relationship to the customers entry. A business term links to the customers entry as its definition. Together, these pieces describe not only what exists but how things connect.

A catalog is only as good as what flows into it, so Dataplex offers automatic, connector-based, and custom ways to load metadata.

Automatic metadata from Google Cloud

For many Google Cloud services, technical metadata arrives without you doing anything. Google’s documentation lists sources including BigQuery (with related items such as sharing listings and Dataform), Dataproc Metastore, Iceberg REST catalogs, Vertex AI, Bigtable, Spanner, and Pub/Sub, with Cloud Storage handled through discovery. AlloyDB and Cloud SQL can be added after enabling the integration, and Looker support is listed as a preview. Because this metadata is collected automatically, new tables appear in the catalog soon after they are created.

Discovery scans for files

Files in Cloud Storage have no built-in table definitions, so Dataplex can run discovery scans that look inside buckets, recognize structured data such as common file formats, work out the columns, and register the results as catalog entries. This turns a pile of files into something people can search and even query.

Third-party and custom sources

Few companies keep everything in Google Cloud. Google’s documentation mentions connectors for third-party systems such as dbt Core, Oracle, MySQL, PostgreSQL, and SQL Server, plus managed connectivity pipelines and custom ingestion through open APIs. A custom import lets you load metadata from an in-house system, so the catalog becomes a single view across the whole company rather than just one cloud.

flowchart LR
  A["Google Cloud services: BigQuery, Pub/Sub, Spanner, and more"] --> C["Knowledge Catalog index"]
  B["Cloud Storage discovery scans"] --> C
  D["Third-party connectors: databases, dbt, and others"] --> C
  E["Custom ingestion through APIs"] --> C
  C --> F["Search, glossary, quality, lineage, governance"]
  C -. "Change feed to Pub/Sub" .-> G["Downstream tools and automation"]
        

Change feeds keep other tools in sync

Catalog information is useful beyond the catalog itself. Google’s documentation describes change feeds that send near real-time notifications of metadata changes to a Pub/Sub topic. A security tool could react when a table’s sensitivity label changes, or a data platform could refresh its documentation site whenever descriptions are edited.

Search is the front door of the catalog. If people cannot find data quickly, nothing else matters.

What search covers

Search looks across entries and their metadata, so a query can match a table name, a column name, a description, or a business term. Google’s documentation says search requires one of the catalog roles, such as Viewer, Editor, or Admin, and that results are limited to the same organization and the same VPC Service Controls perimeter. It also notes that the search API does not search across organizations. Creating and managing catalog resources, search calls, and console search are described as free of charge, while metadata storage is billed.

Keyword and natural language search

Traditional search matches words. Newer capabilities also let people ask questions in plain language, such as “Which tables hold monthly subscription revenue?”, and use AI to find relevant assets. Google’s documentation describes use cases where an agent answers natural-language queries about data assets through the API, and where a single request returns context about assets that a language model can use. These capabilities make the catalog useful not only to people but also to AI applications that need to know which data to trust.

Making search results trustworthy

Finding an asset is only half the job. A good result page tells the searcher what the asset is, who owns it, how fresh it is, whether it has passed quality checks, which business terms it matches, and where it came from. Without these signals, people find ten similar tables and have no idea which one to use. This is why the catalog connects search with quality scores, lineage, and glossary links.

A glossary gives the whole company one shared language, which is often the biggest source of confusion in data work.

Why a glossary matters

Ask three departments to define “active customer” and you may get three answers. Sales counts anyone who bought this year. Support counts anyone with an open account. Finance counts anyone who paid in the last ninety days. All three are reasonable, yet reports using different meanings under one name cause endless arguments. A business glossary records agreed definitions, so everyone knows which meaning a given number uses.

Google’s documentation describes a glossary as a taxonomy of business terms that you can link to columns and assets, and use to find assets by term. Terms can be grouped into categories, and links such as synonym and definition show how terms relate to each other and to the data.

Linking terms to data

A glossary becomes powerful when terms point to real columns. If the term “Customer ID” links to the matching columns in five tables, a person searching for the term finds all five at once, and a data steward can see where a definition is actually in use. If a definition changes, the people responsible can find every affected asset.

Enrichment: adding meaning at scale

Adding descriptions to thousands of tables by hand is unrealistic. Google’s use-case page describes enrichment, including an example agent that generates AI-powered overviews of data assets at scale. Generated descriptions give people a useful starting point, which human owners then review and correct. Treat generated text as a draft, not a final fact, particularly for sensitive or business-critical assets.

Quality scans act like inspectors who test your tables against written rules, on a schedule, and report what they find.

What data quality means

Good data is accurate, complete, fresh, consistent, and unique. Bad data looks normal until someone makes a decision with it. A missing country code, a negative price, a duplicated order, or a table that stopped updating three days ago can quietly spoil every report built on top. Automatic data quality lets you turn those worries into checks that run without anyone remembering to look.

How a scan works

Google’s documentation explains that an auto data quality scan targets one table and tests it against rules you define. Scans run on a schedule or on demand, produce quality scores, and log alerts when records fail. Supported table types include BigQuery tables, Iceberg REST catalog tables, SAP Business Data Cloud Delta Lake tables, and Apache Hive tables. The scan runs in a Google-managed tenant project, so you do not provision or maintain any machines for it.

The kinds of rules

Google describes row-level rules, which test each row against a passing threshold percentage, and aggregate rules, which test one value across the whole table. Custom SQL rules can be a row condition, a table condition, or an assertion that returns the rows that break a rule. Every rule is assigned to a quality dimension, with the predefined set including freshness, volume, completeness, validity, consistency, accuracy, and uniqueness. A scan can hold up to one thousand rules.

flowchart LR
  T["BigQuery table"] --> S["Quality scan with rules"]
  S --> R["Scores by job, dimension, column"]
  R --> BQ["Results exported to BigQuery"]
  R --> CAT["Quality scorecard on catalog page"]
  R --> AL["Logs and email alerts when score drops"]
  BQ --> L["Looker dashboards"]
        

Controlling cost and scope

Scanning huge tables repeatedly can be expensive, so scans offer controls. You can sample a percentage of records, apply row filters to limit what is scanned, and run incremental jobs that look only at new data using a date or timestamp column as a marker. Running jobs can be canceled. Google also notes that Private Google Access must be enabled on the subnet used by the scan.

Profiling shows what your data really looks like, and results turn quality from a feeling into numbers people can act on.

Profiling first, rules second

Before writing rules you need to know what is normal. Data profiling computes statistics for each column of a table, such as the smallest and largest values, the share of empty values, the number of distinct values, and common patterns. Google’s use-case page describes profiling a BigQuery table for column statistics and anomalies, then configuring and running a quality scan. The documentation also lists profiling-based recommendations as one source of rules, so the profile can suggest sensible starting checks.

Reading scores at different levels

Scores show the percentage of rules passed. According to Google’s documentation, they can be viewed at the level of a whole job, of each quality dimension, and of each column, although column-level scores are available through the API. A table might score ninety-eight percent overall yet only seventy percent on freshness, which tells you the contents are fine but the pipeline is late. Looking at dimensions points you to the kind of problem rather than just its existence.

Finding the bad rows

A failing score is only the start. People then need to know which records broke the rule so they can repair the source. Google describes a query that retrieves failed rows, returning all columns of the table. Teams commonly route failed rows to a repair queue or quarantine table, so that downstream users see only trusted records while owners fix the rest.

Publishing scores where people look

Google’s documentation says results can be published as catalog metadata, shown on the table’s data quality tab, and exported to BigQuery for dashboards in Looker. Publishing scores on the catalog page lets an analyst judge trustworthiness at the very moment of choosing a table.

Lineage is the family tree of your data, showing where each table came from and what depends on it.

What lineage records

When a job reads a table, transforms it, and writes another table, lineage records the link. Over time these links form a graph that shows, for any asset, which sources fed it and which reports, models, or tables rely on it. Google describes lineage as automatically tracking data flows, including how sensitive information moves through pipelines.

How lineage is captured

Google’s documentation says lineage from BigQuery, Managed Airflow (Cloud Composer), Cloud Data Fusion, and Managed Service for Apache Spark (Dataproc) appears in the same interface. For other tools, an open standard called OpenLineage lets pipelines send events describing which datasets a job read and wrote. Dataplex can import these events, and some services, such as Spark and Airflow, have built-in producers that send events automatically. The documentation also mentions client libraries and an OpenLineage transport for tools such as Airflow, Spark, and Flink.

sequenceDiagram
  participant J as Pipeline job
  participant P as OpenLineage producer
  participant L as Lineage API
  participant U as Lineage graph in console
  J->>P: Job reads table A and writes table B
  P->>L: Send run event with inputs and outputs
  L->>L: Store process, run, and lineage event
  U->>L: Analyst opens table B
  L-->>U: Show table A upstream and reports downstream
        

What lineage is good for

Know the limits

The lineage graph shows inputs and outputs for each run, but not every low-level step, such as individual Spark stages. Google documents limits on imported events, including a maximum message size of five megabytes and caps on the number of links per event. The imported API supports the first major version of the OpenLineage standard. Check current limits when you design large pipelines.

A data product packages related assets with an owner and a purpose so other teams can adopt them with confidence.

From loose tables to products

A shared warehouse often contains hundreds of tables, and nobody is sure which are meant for general use. A data product changes that mindset. Instead of exposing raw tables, a team publishes a curated bundle, such as “Customer 360”, that includes the right tables, clear descriptions, an owner, quality expectations, and information about how to request access. Consumers search for the product, not for a half-remembered table name.

Domains give ownership a home

Large companies group data by business area, called domains, such as sales, marketing, supply chain, and finance. Each domain’s team knows its data best and is best placed to publish and maintain products. Google’s documentation lists data products and data domains within the service, and third-party summaries describe data products as generally available in 2026. Because this area is evolving, check the current status and limits in the documentation before building a large program on it.

Governance means the right people see the right data, with rules that are written down once and applied everywhere.

Layers of control

Dataplex works alongside Google Cloud’s normal security tools rather than replacing them. Access to catalog resources is controlled through Identity and Access Management, and Google’s documentation notes that roles such as catalog admin, editor, and viewer decide who can search and manage metadata. Entry groups carry their own access control, so a sensitive drawer of entries can be restricted even when other groups are open.

Classify first, then protect

You cannot protect sensitive data you have not identified. A common approach is to tag columns that hold personal information, financial details, or health data, and then attach security rules to those tags. When a new table arrives with a matching column, the same protection can follow. Lineage then adds a safety net by showing where tagged data flows, so you can spot copies that escaped the rules.

Separate who manages from who reads

Managing metadata and reading data are different powers. A person who edits glossary terms does not automatically need permission to read the underlying tables. Likewise, an analyst who reads tables should not be able to rewrite catalog policies. Separating duties limits the damage from mistakes and compromised accounts.

Dataplex began with lakes and zones, ideas that still help explain how to organize data stored in files.

The original model

When Dataplex was introduced, it organized data into three layers. A lake was a logical home for related data, such as everything belonging to a business area. A zone divided a lake by readiness, commonly a raw zone for data exactly as it arrived and a curated zone for cleaned, trusted data. An asset was a Cloud Storage bucket or a BigQuery dataset attached to a zone. This structure let teams apply rules, discovery, and security consistently to data spread across many buckets and datasets.

Where this fits today

Google’s current catalog documentation focuses on entries, aspects, glossaries, lineage, quality, and data products, and it notes that lakes, zones, assets, and entities cannot be registered as catalog entries. That means the older lake model and the newer catalog model are distinct. If your organization has existing lakes and zones, check the current documentation to see which features still apply to them and how Google recommends transitioning. For new work, designing around the catalog, data products, and standard Google Cloud resources is the safer direction.

The raw, refined, curated idea lives on

Even when the specific lake and zone objects are not used, the layered thinking remains valuable. Land data raw and untouched, so you can always replay it. Refine it by cleaning and standardizing. Curate it into trusted, well-described products. Each layer has different owners, different quality expectations, and different access rules, and the catalog can record those differences through aspects and entry groups.

flowchart LR
  R["Raw layer: data exactly as received"] --> F["Refined layer: cleaned and standardized"]
  F --> C["Curated layer: trusted products"]
  C --> U["Analysts, dashboards, ML models"]
  Q["Quality scans"] -.-> F
  Q -.-> C
        

Open table formats and the lakehouse

Modern lakehouse designs store data as files in open table formats such as Apache Iceberg, which add reliable tables on top of storage. Google’s documentation mentions Iceberg REST catalogs as a metadata source and as a supported target for quality scans, and describes a governance use case of creating Iceberg tables with centralized column-level security and visualizing automated lineage. The catalog is the shared source of truth that lets many engines understand the same tables.

A governance platform needs its own care, with alerts, ownership, and a routine for fixing the problems it reports.

What to watch

Dataplex generates operational signals you can observe like any other service. Google’s documentation says quality scans write entries to Cloud Logging that can drive alerts, and that email notifications can be sent when a score falls below a target, a job fails, or a job finishes. It also notes that scan costs can be tracked through billing export using labels, and that scans do not emit time-series metrics to Cloud Monitoring, so plan to use logs and billing data rather than expecting standard metric charts.

Troubleshooting routine

Ownership is an operational duty

Every glossary term, aspect type, scan, and data product needs a named owner. When an owner leaves, the item should pass to someone else rather than rot. Many governance programs fail not because the tools are weak, but because nobody feels responsible. Regular review meetings, where owners confirm their items are current, keep the system alive.

Dataplex brings real strengths, but like any platform it has limits and a bill worth understanding.

How the bill is built

Google’s documentation states that storing metadata is billed, while creating and managing catalog resources, search calls, and console search are free. Processing-heavy features, such as quality scans, profiling, discovery, and lineage, consume processing capacity measured in Data Compute Units. A third-party summary of Google’s pricing, published in September 2026, reports different rates for standard processing such as discovery and for premium processing such as quality, profiling, and lineage, a metadata storage rate, and a small monthly free allowance. It also reports a new charge for data insights features starting in late October 2026. Because these figures come from a secondary source and prices change, always confirm current rates on Google’s pricing page and test with your own data volumes.

Practical ways to keep cost sensible

Dataplex compared with other approaches

A handful of tested patterns cover most governance needs in the real world.

flowchart TD
  P["Pipeline writes to staging table"] --> Q{"Quality scan passes?"}
  Q -- "Yes" --> C["Publish to curated layer"]
  Q -- "No" --> X["Quarantine failed rows and alert owner"]
  C --> CAT["Catalog shows fresh score and lineage"]
  X --> FIX["Owner fixes source, rerun pipeline"]
  FIX --> P
        

The diagram shows the pattern’s heart: bad data never reaches consumers, owners are alerted, and the cycle repeats until the problem is fixed. This one pattern prevents a large share of the “who changed my numbers?” incidents.

Most governance programs stumble over a short list of repeated mistakes.

A short checklist of habits separates thriving governance programs from abandoned ones.

Habits that pay off

Moving from the older Data Catalog

Many organizations still have tags and templates from the older Data Catalog service. Google publishes a transition guide, and notes that aspect types succeed tag templates. A third-party summary from September 2026 reports that the legacy service began shutting down in June 2026, and lists migration gaps, such as private tag templates having no direct counterpart, regional tag templates becoming global aspect types so name collisions matter, and limits in managing certain custom items through infrastructure tooling. Because the transition details can change and sources describe the timeline differently, read Google’s current guide before planning a migration, inventory your existing tags, and test with a small subset first.

Mistakes that appear again and again

Walking through realistic situations shows how the ideas fit together.

A Ninety-Day Rollout Plan for a New Team

Teams often ask how to turn all these ideas into a calendar. A realistic first quarter has three phases, each with a small, visible result that builds confidence for the next one.

During the first month, focus on visibility. Enable the catalog in the projects that hold your most important warehouse data, and confirm that automatic metadata appears for tables and files. Choose one business domain, such as sales, and ask its owners to review descriptions for the ten tables people use most. Create a short list of glossary terms for the metrics that cause the most arguments. Teach analysts how to search, and collect their first complaints about missing or confusing results. The goal of this phase is simple: people can find the important data and see who owns it.

During the second month, focus on trust. Run profiling on the critical tables to learn what normal looks like, then add a few quality rules for completeness, uniqueness, and valid ranges. Send alerts to a real mailbox or channel that somebody watches, and agree on who responds and how fast. Connect scan results to the catalog so consumers see scores beside the table description. Review lineage for the most important reports and note any gaps where a tool sends no events. The goal of this phase is that people trust the data more, and problems are noticed before executives notice them.

During the third month, focus on scale and protection. Add sensitivity tags and column-level access rules for personal data, document the approval path for requesting access, and publish the first data products for the domain that went first. Measure adoption through search activity, the share of key tables with owners and descriptions, and the number of quality incidents caught early. Present these numbers to leadership, then use the results to bring the next domain on board. The goal of this phase is a repeatable pattern that other teams can copy without starting from scratch.

Roles That Make The Program Work

Governance succeeds when responsibilities are clear. A data owner is accountable for a dataset, approves access, and answers questions about meaning. A data steward looks after daily quality, descriptions, and glossary terms, acting as the practical caretaker. A platform engineer maintains the technical setup, such as permissions, scans, and ingestion. A consumer, such as an analyst or scientist, uses the data and reports problems back. When a catalog entry names all four roles, nobody has to guess whom to contact, and problems travel to the right person quickly instead of circulating in chat threads.

Quick answers to the questions that come up most often.

No. It does not store your business data. It catalogs, describes, checks, and governs data that lives in services such as BigQuery and Cloud Storage.

Yes. Google’s documentation says Dataplex Universal Catalog was renamed Knowledge Catalog on April 10, 2026, and that API, library, command line, and role names did not change, which is why Dataplex still appears in technical names.

Data is the content itself, such as customer orders. Metadata is information about that content, such as the table name, owner, column meanings, and quality score.

An aspect type is a reusable template of metadata fields. An aspect is that template filled in and attached to an entry. Aspect types succeed the tag templates of the older Data Catalog.

Google’s documentation says search calls and console search are free, and that creating and managing catalog resources is free, while metadata storage is billed. Processing features such as scans consume billable processing capacity.

According to Google’s documentation, supported table types include BigQuery tables, Iceberg REST catalog tables, SAP Business Data Cloud Delta Lake tables, and Apache Hive tables. Each scan targets one table.

Google documents a limit of one thousand rules per scan. Start with a few meaningful rules rather than approaching the limit.

Automatically for several Google Cloud services such as BigQuery, Managed Airflow, Data Fusion, and Dataproc, and through OpenLineage events imported from other tools that produce them.

Yes, through connectors for several third-party systems, managed connectivity pipelines, and custom ingestion through open APIs, though some automated features may be limited to built-in Google Cloud services.

People with a catalog role such as viewer, editor, or admin. Results are limited to the same organization and service perimeter, and they respect permissions on entry groups.

They were central to the original Dataplex. Google’s catalog documentation says lakes, zones, assets, and entities cannot be registered as catalog entries, so check current guidance if you use them. The raw, refined, and curated layering idea remains useful either way.

Pick one important domain, let automatic metadata fill the catalog, add owners and descriptions to the key tables, define a handful of glossary terms, and add quality scans to the two or three most critical tables.

Yes. Google’s use-case page describes agents that search the catalog with natural language and retrieve context about data assets, so AI applications can find and understand the right data.

Dataplex is the librarian, inspector, and security desk for your data. It builds a searchable catalog on top of data that stays where it is, adds meaning through glossaries and aspects, checks health through profiling and quality scans, records history through lineage, and applies protection through consistent policies. The platform and its names have evolved, but the goal is stable: make data easy to find, safe to trust, and safe to share. Tools help, but results come from habits: named owners, small clear templates, meaningful checks, and routines that keep metadata alive.