You cannot govern data you have not inventoried.
The catalog is the system of record for what Data.co Control can reach: every source, dataset, field, and document collection, who owns it, how it is labeled, and which identities and agents use it. Policies, classification, and lineage all refer to the catalog by name.
A catalog built for access decisions, not just discovery.
Traditional data catalogs help analysts find tables. That is useful, but an AI governance catalog has a stricter job: it has to be complete for everything AI can reach, and accurate enough for a policy engine to rely on it. If a dataset is not in the catalog, Control cannot connect it; if a field's label is wrong, a policy will act on the wrong information.
The catalog is populated by connectors as they profile sources, not by hand. Data owners then confirm labels and descriptions, so the catalog reflects both what the systems contain and what the business says about it.
What is recorded for each asset.
| Attribute | Example | Used by |
|---|---|---|
| Identifier | dataset:ehr.clinical_notes | Policies, lineage, audit records |
| Owner | group:clinical-informatics | Label review, approvals routed to owner |
| Classification | PHI (confirmed), PII (confirmed) | Policy conditions, DLP egress rules |
| Schema or structure | Fields, types, document collections | Query constraints, field-level labels |
| Source permissions model | Row owner group, NTFS ACLs, site permissions | Permission-aware retrieval |
| Sync state | Last sync, mode, status | Freshness checks, lineage |
| AI usage | Agents and applications that accessed it | Access reviews, monitoring |
Query the catalog from your own tools.
The catalog is available through an API inside your deployment, for access reviews, reporting, or wiring into an existing governance tool.
curl -s https://control.internal/api/catalog/assets \
-H "Authorization: Bearer $CONTROL_TOKEN" \
-G --data-urlencode 'classification=PHI' \
--data-urlencode 'used_by_type=agent'Illustrative example · final API surface documented in /docs
What teams do with it.
Access reviews
List every identity and agent that has touched a classified asset in a period, and which policy allowed it.
Ownership gaps
Find connected datasets without an owner or with unconfirmed labels before they are opened to AI use.
Policy authoring
Write policies against catalog identifiers and labels instead of hard-coded table names.
Scoping new AI use
Check what data a proposed agent would need, and how it is classified, before granting scope.
How an asset goes from discovered to usable.
An asset does not become available to AI just because a connector can see it. It moves through stages, and each stage is visible in the catalog.
- 1
Discovered
A connector finds a new table, field, folder, or collection while profiling a source, and registers it with a stable identifier.
- 2
Profiled
Structure, permissions model, and sync state are recorded; classifiers propose labels for fields and documents.
- 3
Owned
An owning team is assigned. Ownership decides who confirms labels and who is asked when access falls outside the baseline.
- 4
Confirmed
The owner confirms or corrects labels and adds a description. Confirmed labels become the basis for policy decisions.
- 5
Referenced
Policies and agent scopes name the asset by identifier, and the simulator shows who can reach it before it goes live.
Policies should name assets, not guess at them.
When policies reference raw table names or file paths, small changes in a source break governance in quiet ways: a renamed schema, a migrated SharePoint site, or a new copy of a table in a reporting database. The catalog gives every asset a stable identifier, and glob patterns over those identifiers, such as every dataset under ehr, let one rule cover a family of assets without listing each one.
The catalog also gives policies the attributes they condition on. A rule that limits analysts to claims in their own region needs the region attribute to exist on the dataset and on the user. Keeping those attributes in one governed inventory, rather than scattered across configuration files, is what makes attribute-based rules maintainable over time.
Before an asset is opened to AI use.
- It has a named owning team
- Sensitive labels are confirmed, not only proposed
- Its source permissions model is captured and current
- Its last successful sync is within the expected window
- Policies that reference it have passing tests
- Agents that will use it are listed in its usage
Questions buyers ask
Does this replace our existing data catalog?
Not necessarily. The Control catalog covers what AI can reach and the metadata policies need. If you run an enterprise catalog, it can remain the place analysts discover data; integration between the two is scoped per deployment.
How is the catalog kept current?
Connectors update it as they profile and sync sources. Schema changes and new collections appear automatically and are flagged for label review.
Who can see the catalog?
Catalog access is governed by Control roles. Metadata such as field names can itself be sensitive, so visibility can be restricted per source.
Is catalog metadata sent to Data.co?
No. The catalog lives in the runtime in your environment. The hosted account plane does not receive it.
What happens to assets that never get an owner?
They stay visible as ownership gaps. Policies can treat unowned or unconfirmed assets conservatively, for example keeping them out of agent scope until an owner signs off on their labels.
Does the catalog track which agents use an asset?
Yes. Usage is drawn from decisions at the enforcement points, so the catalog can list the agents and applications that accessed an asset, which is the starting point for an access review.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.